JAAS (like Shiro and other frameworks) ultimately relies on JavaSE's java.security.AccessController - as does java.lang.SecurityManager. So these frameworks effectively replace the SecurityManager - and as they do not link access to a code source they don't need the stack-inspection magic that SecurityManager needs.
> 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 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
