You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Karl Pauls <ka...@gmail.com> on 2008/02/27 11:19:55 UTC
Re: Security Aspects of the ServiceLocator (was: [Proposal] ServiceLocator)
> Hi Alex,
>
> Am Dienstag, den 26.02.2008, 17:57 +0100 schrieb Alexander Saar:
> > I have only one question that is due to my limited knowledge of OSGI.
> > Is there anything like a security concept that controls access to
> > OSGI services? As far as I understand the proposed changes the service
> > locator will then use the BundleContext from the bundle that provides
> > the according script engine. Can such a service locator always access
> > every registered OSGI service? If not how can I control the access?
>
> Probably the ServiceLocator will use the BundleContext of the
> scripting/resolver bundle and not that of any specific scripting engine.
> But this is a minor detail in this discussion.
>
> Point is, that is theoretically possible to limit the accessibility to
> services for certain bundles (and even users IIRC). This is specified in
> the security part of the core OSGi specification. It is also possible to
> limit certain method calls (e.g. Bundle.stop()) as specified for the
> respective method.
Right, the OSGi spec considers security and builds it's own permission
management infrastructure on top of Java security. Basically, in
addition to the normal Java permission checks all other OSGi related
operations are doing their own permission checks.
> So if we provide a ServiceLocator based on a certain bundle, we of
> course inherit the security context of said bundle. No for code provided
> by bundles (e.g. OSGi services or bundle-based scripts) this may be
> fixed by using the appropriate BundleContext to access services.
Depending on what exactly you have in mind it might be some work
involved but it is definitely possible to get this done.
> But for JCR based scripts, this is different and would probably be based around
> user-based security.
It should be possible to merge user-based security with the code based
one of OSGi. In general, this is not part of the spec but it is
doable.
> Currently, we do not have this level of security enforced. And I have to
> admit, that this is not currently the part of the OSGi specification I
> understand the best ... Maybe Karl Pauls may be able to jump in, if I
> got something completely wrong.
One issue to keep in mind is that for OSGi security to work we will
have to run with security enabled :-). This will definitely eat some
performance.
Another one is that we would need to look into all of the sling core
to give it the right permissions or at least configure a catch all
permission for sling core things.
Finally, Felix doesn't have security right now but I'm almost ready to
commit a first version (probably by the end of the week).
> Hope this helps.
>
> Regards
> Felix
btw. Marcel and I will give a OSGi security tutorial at eclipsecon next month:
http://www.eclipsecon.org/2008/?page=sub/&id=300
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: Security Aspects of the ServiceLocator (was: [Proposal] ServiceLocator)
Posted by Alexander Saar <al...@googlemail.com>.
Definitely.
Am 28.02.2008 um 10:36 schrieb Bertrand Delacretaz:
> On Thu, Feb 28, 2008 at 10:28 AM, Alexander Saar
> <al...@googlemail.com> wrote:
>> ...in future there might be a
>> concept for mapping JCR user rights to OSGI service access, right?...
>
> I'd make sure that's "in the future" and "if someone ever needs
> that" ;-)
>
> I'm sure we have much more urgent things to work on at the moment.
>
> -Bertrand
Re: Security Aspects of the ServiceLocator (was: [Proposal] ServiceLocator)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Feb 28, 2008 at 10:28 AM, Alexander Saar
<al...@googlemail.com> wrote:
> ...in future there might be a
> concept for mapping JCR user rights to OSGI service access, right?...
I'd make sure that's "in the future" and "if someone ever needs that" ;-)
I'm sure we have much more urgent things to work on at the moment.
-Bertrand
Re: Security Aspects of the ServiceLocator (was: [Proposal] ServiceLocator)
Posted by Alexander Saar <al...@googlemail.com>.
So, ATM I'm able to access every service that is deployed into Sling,
regardless which BundleContext is used and in future there might be a
concept for mapping JCR user rights to OSGI service access, right? I
have currently no real use case in mind but I can imagine that such a
functionality in Sling might be useful in times of open systems and
web communities, because it is not necessary to develop own concept
for handling access to different service depending on users rights.
Thanks for clarification.
Regards,
Alex
Am 27.02.2008 um 11:19 schrieb Karl Pauls:
>> Hi Alex,
>>
>> Am Dienstag, den 26.02.2008, 17:57 +0100 schrieb Alexander Saar:
>>> I have only one question that is due to my limited knowledge of
>>> OSGI.
>>> Is there anything like a security concept that controls access to
>>> OSGI services? As far as I understand the proposed changes the
>>> service
>>> locator will then use the BundleContext from the bundle that
>>> provides
>>> the according script engine. Can such a service locator always
>>> access
>>> every registered OSGI service? If not how can I control the access?
>>
>> Probably the ServiceLocator will use the BundleContext of the
>> scripting/resolver bundle and not that of any specific scripting
>> engine.
>> But this is a minor detail in this discussion.
>>
>> Point is, that is theoretically possible to limit the accessibility
>> to
>> services for certain bundles (and even users IIRC). This is
>> specified in
>> the security part of the core OSGi specification. It is also
>> possible to
>> limit certain method calls (e.g. Bundle.stop()) as specified for the
>> respective method.
>
> Right, the OSGi spec considers security and builds it's own permission
> management infrastructure on top of Java security. Basically, in
> addition to the normal Java permission checks all other OSGi related
> operations are doing their own permission checks.
>
>> So if we provide a ServiceLocator based on a certain bundle, we of
>> course inherit the security context of said bundle. No for code
>> provided
>> by bundles (e.g. OSGi services or bundle-based scripts) this may be
>> fixed by using the appropriate BundleContext to access services.
>
> Depending on what exactly you have in mind it might be some work
> involved but it is definitely possible to get this done.
>
>> But for JCR based scripts, this is different and would probably be
>> based around
>> user-based security.
>
> It should be possible to merge user-based security with the code based
> one of OSGi. In general, this is not part of the spec but it is
> doable.
>
>> Currently, we do not have this level of security enforced. And I
>> have to
>> admit, that this is not currently the part of the OSGi
>> specification I
>> understand the best ... Maybe Karl Pauls may be able to jump in, if I
>> got something completely wrong.
>
> One issue to keep in mind is that for OSGi security to work we will
> have to run with security enabled :-). This will definitely eat some
> performance.
>
> Another one is that we would need to look into all of the sling core
> to give it the right permissions or at least configure a catch all
> permission for sling core things.
>
> Finally, Felix doesn't have security right now but I'm almost ready to
> commit a first version (probably by the end of the week).
>
>> Hope this helps.
>>
>> Regards
>> Felix
>
> btw. Marcel and I will give a OSGi security tutorial at eclipsecon
> next month:
>
> http://www.eclipsecon.org/2008/?page=sub/&id=300
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpauls@gmail.com