In the upcoming transaction composition spec we’re discussing setting a
standard for this piece of code that receives the external request. The
Coordinator will likely play a role. In OSGi enRoute, we mandated that the
Authority service should be set, which is also thread based. Java security was
not possible because we needed to transfer the permission info to the external
GUI code. (We still verify it on the server of course, but I think it sucks
when you press a button you’re not supposed to press.) The Java security
permission model hides this information by classes that cannot be transferred
to another system.
Kind regards,
Peter Kriens
> On 2 mrt. 2016, at 09:03, Guillaume Nodet <gnodet.apa...@gmail.com> wrote:
>
> 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 <peter.kri...@aqute.biz
> <mailto:peter.kri...@aqute.biz>>:
> 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 <mailto: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
>>> <mailto: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 <mailto: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
>>>>> <mailto: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 <mailto: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 <http://www.liquid-reality.de/>
>>>>>>
>>>>>> Open Source Architect
>>>>>> http://www.talend.com <http://www.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>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>>>>>
>>>>> Open Source Architect
>>>>> http://www.talend.com <http://www.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>
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> 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 <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
>
>
> --
> -----------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com <mailto:gno...@redhat.com>
> Web: http://fusesource.com <http://fusesource.com/>
> Blog: http://gnodet.blogspot.com/ <http://gnodet.blogspot.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
