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, chris.g...@kiffer.be 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 <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 <http://www.liquid-reality.de/>
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.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 <http://www.talend.com/>
>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.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 <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <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
