The AccessControlContext is simply used as an independent vehicle to transport the logged in user and the groups. It allows for example CXF to set the authentication information in a CXF interceptor and the blueprint authz module to read the authentication. As JAAS is available in standard java the login can be transported without introducing a dependency between CXF and blueprint.
The security is then for example enforced by a blueprint interceptor (blueprint-authz) or by java code. This security measure is not meant to protect against unauthorized code. It is only on application level like Guillaume explained. Christian 2016-03-01 9:47 GMT+01:00 Peter Kriens <peter.kri...@aqute.biz>: > So no security manager and you can still use the AccessControlContext? > That surprises me and makes me wonder what it means? Without a security > manager, I do not understand how the checks are done, nor how they can be > enforced? > > Kind regards, > > Peter Kriens > > > > > On 1 mrt. 2016, at 00:33, Christian Schneider <ch...@die-schneider.net> > wrote: > > > > I will have to look into Conditional Permission admin. > > I only use JAAS to do the authentication and make the > AccesControlContext available on the thread via: > > AccessControlContext acc = AccessController.getContext() > > The nice thing is that this allows other parts of the code to do > authorization decisions without being coupled to any special security > library. > > I do not use the SecurityManager. > > The JAAS approach is already used in many places. For example the karaf > web console populates the AccessControlContext on the web console and the > console. Karaf also checks the authorization of commands executed on the > shell this way. CXF populates the AccessControlContext from the service > authentication information. Aries blueprint can do annoation based > authorization using @RolesAllowed. > > So a nice way to run a bundle as a certain user would play very nicely > together with these mechanisms. Of course you can already do a JAAS login > with code but it is a lot of boiler plate code. > > Christian > > > > > > 2016-02-29 8:42 GMT+01:00 Peter Kriens <peter.kri...@aqute.biz>: > > There is no standardized solution for this. In general, Bundle > Activators are called on the thread the start method is called but this is > not guaranteed and for DS you’er out of luck. > > > > That said, I am a bit puzzled by the model. JAAS is based on the same > (terrible) security model the VM gave us. Why not use Conditional > Permission admin to just manage the required permission for that bundle, > that you can do standardized and quite easy? > > > > Kind regards, > > > > Peter Kriens > > > > > On 28 feb. 2016, at 12:09, Christian Schneider < > ch...@die-schneider.net> wrote: > > > > > > When working with JAAS based authentication it is necessary to run the > code as a certain subject. > > > > > > For code that is called from the outside as well as from the karaf > shell there are existing solutions to do the login. > > > I wonder if there is an OSGi mechanism to do the same for code that is > started inside a bundle. (Activator, blueprint or DS). > > > What I would like to have is some way to say: The startup code for > this bundle should run as a certain user. > > > > > > Is this already possible or would I have to create such a mechanism > myself? > > > > > > Christian > > > > > > -- > > > Christian Schneider > > > http://www.liquid-reality.de > > > > > > Open Source Architect > > > http://www.talend.com > > > > > > _______________________________________________ > > > OSGi Developer Mail List > > > osgi-dev@mail.osgi.org > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > > OSGi Developer Mail List > > osgi-dev@mail.osgi.org > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > -- > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > http://www.talend.com > > _______________________________________________ > > OSGi Developer Mail List > > osgi-dev@mail.osgi.org > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
