In all cases, you need to convey the information about the user executing the code. This is usually not a problem, as we're talking about external user interactions here, so there's always a piece of code which receive the external request and execute it. It's not about authenticating the bundle's code origin, but a *real* user.
Guillaume 2016-03-01 22:48 GMT+01:00 Peter Kriens <[email protected]>: > But it is then just a current-thread stack based mechanism? So to make > this work as Christian wants means you must be on the beginning of > everybody’s thread? > > Kind regards, > > Peter Kriens > > On 1 mrt. 2016, at 19:35, [email protected] wrote: > > 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 <[email protected]>: > > 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 > > <[email protected]> > 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 <[email protected]>: > 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 < > > [email protected]> 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 > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > 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 > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > 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 > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
