Think about application level security, similar to servlet security ? There may be no need to do security at the JVM level in those cases.
Guillaume 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 > -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev