Some thoughts around adding security for Karaf Shell Commands

[da...@apache.org]

Hi all,

In the context of KARAF-2442 I started looking at securing the commands in
the shell. I wanted to do something similar to what I did for the JMX
access (KARAF-2435) in that this should be configurable by a Karaf
administrator. I also really wanted a generic solution that would work with
all commands, so that there would not be a big burden on the command
developer. I know that there was discussion about this in the context of
Karaf before, my approach here is a bit different...

Here's what I came up with…
Karaf Commands are implemented OSGi services and one of the lesser known
features of the OSGi service registry is the fact that you can control
service registrations through service registry hooks. This effectively
allows you to change registrations, control who sees what registrations and
also proxy service objects with some interceptor [1].
I thought that this might be a nice tool to use to add security to the
Karaf Commands from the outside, so I started an experimental
implementation with this:
* The roles that a specific Karaf Command needs in order to be executable
are defined in a ConfigAdmin config file in the etc/ directory. So this can
easily be modified by an administrator. E.g I have a file that controls who
can use the feature command, some example content:
  list = manager, viewer
  install = manager
  uninstall = admin
* I added a mechanism that effectively changes command service
registrations to add the required roles for the specific command - based on
the ConfigAdmin data specified, e.g. the Service Registration for a
features:list command is turned into the following:
  osgi.command.scope=feature
  osgi.command.function=list
  org.apache.karaf.command.roles=[manager,viewer]
* The CommandProcessorImpl class in Karaf keeps track of what commands are
there. Previously this was a global instance, but now we need one instance
per shell console that selects the right commands for the user of that
console. It does this by reading off the current RolePrincipal objects
(that were put there by the JAAS login) and only selecting those commands
that have these roles by simply adding these as additional conditions to
the OSGi Service Registry selection filter.
* From there on everything works as normal. Tab completion etc, 'just
works'.

The commands themselves are not modified. The required roles are added
externally, which is really easy for the command developer.
It's also pretty easy to change the required roles for commands either
directly in the etc/...cfg files or via the ConfigAdmin API...

There are still a few things that I need to look at in more detail
(including defaults), but I wanted to run this by everyone to see what
people think, so feedback is appreciated!
If you're interested, I implemented this on a branch here:
https://github.com/bosschaert/karaf/commit/3e16bb515350bfb58e1a4b5d98045ccc1bcb1630

David

davidb@apache.org
david@redhat.com
david.bosschaert@gmail.com

[1] Detail: you don't really change a service registration, but can hide it
from bundles and replace it with an alternative, which gives this effect… I
wrote a blog about this a while ago:
http://coderthoughts.blogspot.ie/2009/11/altering-osgi-service-lookups-with.html

Re: Some thoughts around adding security for Karaf Shell Commands

[Freeman Fang <fr...@gmail.com>]

+1 for this proposal.

I like the idea that we needn't change current commands code, but hack it through service registry hooks.
－－－－－－－－－－－－－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋



On 2013-8-15, at 下午10:26, davidb@apache.org wrote:

> Hi all,
> 
> In the context of KARAF-2442 I started looking at securing the commands in
> the shell. I wanted to do something similar to what I did for the JMX
> access (KARAF-2435) in that this should be configurable by a Karaf
> administrator. I also really wanted a generic solution that would work with
> all commands, so that there would not be a big burden on the command
> developer. I know that there was discussion about this in the context of
> Karaf before, my approach here is a bit different...
> 
> Here's what I came up with…
> Karaf Commands are implemented OSGi services and one of the lesser known
> features of the OSGi service registry is the fact that you can control
> service registrations through service registry hooks. This effectively
> allows you to change registrations, control who sees what registrations and
> also proxy service objects with some interceptor [1].
> I thought that this might be a nice tool to use to add security to the
> Karaf Commands from the outside, so I started an experimental
> implementation with this:
> * The roles that a specific Karaf Command needs in order to be executable
> are defined in a ConfigAdmin config file in the etc/ directory. So this can
> easily be modified by an administrator. E.g I have a file that controls who
> can use the feature command, some example content:
>  list = manager, viewer
>  install = manager
>  uninstall = admin
> * I added a mechanism that effectively changes command service
> registrations to add the required roles for the specific command - based on
> the ConfigAdmin data specified, e.g. the Service Registration for a
> features:list command is turned into the following:
>  osgi.command.scope=feature
>  osgi.command.function=list
>  org.apache.karaf.command.roles=[manager,viewer]
> * The CommandProcessorImpl class in Karaf keeps track of what commands are
> there. Previously this was a global instance, but now we need one instance
> per shell console that selects the right commands for the user of that
> console. It does this by reading off the current RolePrincipal objects
> (that were put there by the JAAS login) and only selecting those commands
> that have these roles by simply adding these as additional conditions to
> the OSGi Service Registry selection filter.
> * From there on everything works as normal. Tab completion etc, 'just
> works'.
> 
> The commands themselves are not modified. The required roles are added
> externally, which is really easy for the command developer.
> It's also pretty easy to change the required roles for commands either
> directly in the etc/...cfg files or via the ConfigAdmin API...
> 
> There are still a few things that I need to look at in more detail
> (including defaults), but I wanted to run this by everyone to see what
> people think, so feedback is appreciated!
> If you're interested, I implemented this on a branch here:
> https://github.com/bosschaert/karaf/commit/3e16bb515350bfb58e1a4b5d98045ccc1bcb1630
> 
> David
> 
> davidb@apache.org
> david@redhat.com
> david.bosschaert@gmail.com
> 
> [1] Detail: you don't really change a service registration, but can hide it
> from bundles and replace it with an alternative, which gives this effect… I
> wrote a blog about this a while ago:
> http://coderthoughts.blogspot.ie/2009/11/altering-osgi-service-lookups-with.html

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi David,

Your proposal looks good. I would just add a couple of other features, 
like command scope management (used for the sub-shell on trunk especially).
I have your patch/pull request on my machine. I gonna review it and get 
back to you.

Thanks !
Regards
JB

On 08/15/2013 04:26 PM, davidb@apache.org wrote:
> Hi all,
>
> In the context of KARAF-2442 I started looking at securing the commands in
> the shell. I wanted to do something similar to what I did for the JMX
> access (KARAF-2435) in that this should be configurable by a Karaf
> administrator. I also really wanted a generic solution that would work with
> all commands, so that there would not be a big burden on the command
> developer. I know that there was discussion about this in the context of
> Karaf before, my approach here is a bit different...
>
> Here's what I came up with…
> Karaf Commands are implemented OSGi services and one of the lesser known
> features of the OSGi service registry is the fact that you can control
> service registrations through service registry hooks. This effectively
> allows you to change registrations, control who sees what registrations and
> also proxy service objects with some interceptor [1].
> I thought that this might be a nice tool to use to add security to the
> Karaf Commands from the outside, so I started an experimental
> implementation with this:
> * The roles that a specific Karaf Command needs in order to be executable
> are defined in a ConfigAdmin config file in the etc/ directory. So this can
> easily be modified by an administrator. E.g I have a file that controls who
> can use the feature command, some example content:
>    list = manager, viewer
>    install = manager
>    uninstall = admin
> * I added a mechanism that effectively changes command service
> registrations to add the required roles for the specific command - based on
> the ConfigAdmin data specified, e.g. the Service Registration for a
> features:list command is turned into the following:
>    osgi.command.scope=feature
>    osgi.command.function=list
>    org.apache.karaf.command.roles=[manager,viewer]
> * The CommandProcessorImpl class in Karaf keeps track of what commands are
> there. Previously this was a global instance, but now we need one instance
> per shell console that selects the right commands for the user of that
> console. It does this by reading off the current RolePrincipal objects
> (that were put there by the JAAS login) and only selecting those commands
> that have these roles by simply adding these as additional conditions to
> the OSGi Service Registry selection filter.
> * From there on everything works as normal. Tab completion etc, 'just
> works'.
>
> The commands themselves are not modified. The required roles are added
> externally, which is really easy for the command developer.
> It's also pretty easy to change the required roles for commands either
> directly in the etc/...cfg files or via the ConfigAdmin API...
>
> There are still a few things that I need to look at in more detail
> (including defaults), but I wanted to run this by everyone to see what
> people think, so feedback is appreciated!
> If you're interested, I implemented this on a branch here:
> https://github.com/bosschaert/karaf/commit/3e16bb515350bfb58e1a4b5d98045ccc1bcb1630
>
> David
>
> davidb@apache.org
> david@redhat.com
> david.bosschaert@gmail.com
>
> [1] Detail: you don't really change a service registration, but can hide it
> from bundles and replace it with an alternative, which gives this effect… I
> wrote a blog about this a while ago:
> http://coderthoughts.blogspot.ie/2009/11/altering-osgi-service-lookups-with.html
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Thanks again JB for reviewing and applying the commits.
I have written a blog article about how it all works here:
http://coderthoughts.blogspot.com/2013/10/role-based-access-control-for-karaf.html

Best regards,

David

On 8 October 2013 16:50, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Awesome, thanks a lot David. I will review it tomorrow morning.
>
> Regards
> JB
>
>
> On 10/08/2013 05:44 PM, David Bosschaert wrote:
>>
>> Hi all,
>>
>> I have the pull request for KARAF-2455 (role-based security for OSGi
>> Services) and KARAF-2442 (role-based security for Karaf Shell
>> Commands) ready.
>> Since KARAF-2442 builds on top of KARAF-2455 (thanks Christian for
>> suggesting this originally) I included both in a single pull requests
>> as two separate commits: https://github.com/apache/karaf/pull/22
>>
>> One note - I have included lots of unit tests (generally > 95%
>> coverage for any of the code I touched) but am also planning to add
>> some system tests. However I'd like to add those system tests
>> separately later.
>>
>> Feedback appreciated,
>>
>> David
>>
>> On 19 September 2013 11:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>
>>> Hi David,
>>>
>>> awesome, thanks for the update. I just started to review the patches. I
>>> will
>>> apply tonight or tomorrow.
>>>
>>> Thanks again,
>>> Regards
>>> JB
>>>
>>>
>>> On 09/19/2013 11:56 AM, David Bosschaert wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> Just a little status update on this...
>>>> I have since implemented most of KARAF-2455 (role-based security for
>>>> OSGi
>>>> Services) and KARAF-2442 (role-based security for Karaf Shell Commands).
>>>> They build on top of what I did for KARAF-2434 and KARAF-2435. Once
>>>> those
>>>> are merge I can rebase my implementation on trunk and will provide
>>>> patches
>>>> to apply...
>>>>
>>>> Cheers,
>>>>
>>>> David
>>>>
>>>>
>>>> On 26 August 2013 10:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>>
>>>>> Thanks David,
>>>>>
>>>>> it makes sense.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/26/2013 11:16 AM, David Bosschaert wrote:
>>>>>
>>>>>> Since I think the general consensus here is that it would be good to
>>>>>> have
>>>>>> a
>>>>>> general security mechanism for OSGi services I have created a JIRA for
>>>>>> that
>>>>>> (KARAF-2455) and noted that role-based security for the commands can
>>>>>> be
>>>>>> built on top of this (KARAF-2442).
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Awesome, thanks a lot David. I will review it tomorrow morning.

Regards
JB

On 10/08/2013 05:44 PM, David Bosschaert wrote:
> Hi all,
>
> I have the pull request for KARAF-2455 (role-based security for OSGi
> Services) and KARAF-2442 (role-based security for Karaf Shell
> Commands) ready.
> Since KARAF-2442 builds on top of KARAF-2455 (thanks Christian for
> suggesting this originally) I included both in a single pull requests
> as two separate commits: https://github.com/apache/karaf/pull/22
>
> One note - I have included lots of unit tests (generally > 95%
> coverage for any of the code I touched) but am also planning to add
> some system tests. However I'd like to add those system tests
> separately later.
>
> Feedback appreciated,
>
> David
>
> On 19 September 2013 11:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi David,
>>
>> awesome, thanks for the update. I just started to review the patches. I will
>> apply tonight or tomorrow.
>>
>> Thanks again,
>> Regards
>> JB
>>
>>
>> On 09/19/2013 11:56 AM, David Bosschaert wrote:
>>>
>>> Hi all,
>>>
>>> Just a little status update on this...
>>> I have since implemented most of KARAF-2455 (role-based security for OSGi
>>> Services) and KARAF-2442 (role-based security for Karaf Shell Commands).
>>> They build on top of what I did for KARAF-2434 and KARAF-2435. Once those
>>> are merge I can rebase my implementation on trunk and will provide patches
>>> to apply...
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>>> On 26 August 2013 10:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>>
>>>> Thanks David,
>>>>
>>>> it makes sense.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/26/2013 11:16 AM, David Bosschaert wrote:
>>>>
>>>>> Since I think the general consensus here is that it would be good to
>>>>> have
>>>>> a
>>>>> general security mechanism for OSGi services I have created a JIRA for
>>>>> that
>>>>> (KARAF-2455) and noted that role-based security for the commands can be
>>>>> built on top of this (KARAF-2442).
>>>>>
>>>>> Cheers,
>>>>>
>>>>> David
>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Hi all,

I have the pull request for KARAF-2455 (role-based security for OSGi
Services) and KARAF-2442 (role-based security for Karaf Shell
Commands) ready.
Since KARAF-2442 builds on top of KARAF-2455 (thanks Christian for
suggesting this originally) I included both in a single pull requests
as two separate commits: https://github.com/apache/karaf/pull/22

One note - I have included lots of unit tests (generally > 95%
coverage for any of the code I touched) but am also planning to add
some system tests. However I'd like to add those system tests
separately later.

Feedback appreciated,

David

On 19 September 2013 11:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi David,
>
> awesome, thanks for the update. I just started to review the patches. I will
> apply tonight or tomorrow.
>
> Thanks again,
> Regards
> JB
>
>
> On 09/19/2013 11:56 AM, David Bosschaert wrote:
>>
>> Hi all,
>>
>> Just a little status update on this...
>> I have since implemented most of KARAF-2455 (role-based security for OSGi
>> Services) and KARAF-2442 (role-based security for Karaf Shell Commands).
>> They build on top of what I did for KARAF-2434 and KARAF-2435. Once those
>> are merge I can rebase my implementation on trunk and will provide patches
>> to apply...
>>
>> Cheers,
>>
>> David
>>
>>
>> On 26 August 2013 10:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>
>>> Thanks David,
>>>
>>> it makes sense.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/26/2013 11:16 AM, David Bosschaert wrote:
>>>
>>>> Since I think the general consensus here is that it would be good to
>>>> have
>>>> a
>>>> general security mechanism for OSGi services I have created a JIRA for
>>>> that
>>>> (KARAF-2455) and noted that role-based security for the commands can be
>>>> built on top of this (KARAF-2442).
>>>>
>>>> Cheers,
>>>>
>>>> David
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi David,

awesome, thanks for the update. I just started to review the patches. I 
will apply tonight or tomorrow.

Thanks again,
Regards
JB

On 09/19/2013 11:56 AM, David Bosschaert wrote:
> Hi all,
>
> Just a little status update on this...
> I have since implemented most of KARAF-2455 (role-based security for OSGi
> Services) and KARAF-2442 (role-based security for Karaf Shell Commands).
> They build on top of what I did for KARAF-2434 and KARAF-2435. Once those
> are merge I can rebase my implementation on trunk and will provide patches
> to apply...
>
> Cheers,
>
> David
>
>
> On 26 August 2013 10:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> Thanks David,
>>
>> it makes sense.
>>
>> Regards
>> JB
>>
>>
>> On 08/26/2013 11:16 AM, David Bosschaert wrote:
>>
>>> Since I think the general consensus here is that it would be good to have
>>> a
>>> general security mechanism for OSGi services I have created a JIRA for
>>> that
>>> (KARAF-2455) and noted that role-based security for the commands can be
>>> built on top of this (KARAF-2442).
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Hi all,

Just a little status update on this...
I have since implemented most of KARAF-2455 (role-based security for OSGi
Services) and KARAF-2442 (role-based security for Karaf Shell Commands).
They build on top of what I did for KARAF-2434 and KARAF-2435. Once those
are merge I can rebase my implementation on trunk and will provide patches
to apply...

Cheers,

David


On 26 August 2013 10:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Thanks David,
>
> it makes sense.
>
> Regards
> JB
>
>
> On 08/26/2013 11:16 AM, David Bosschaert wrote:
>
>> Since I think the general consensus here is that it would be good to have
>> a
>> general security mechanism for OSGi services I have created a JIRA for
>> that
>> (KARAF-2455) and noted that role-based security for the commands can be
>> built on top of this (KARAF-2442).
>>
>> Cheers,
>>
>> David
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Thanks David,

it makes sense.

Regards
JB

On 08/26/2013 11:16 AM, David Bosschaert wrote:
> Since I think the general consensus here is that it would be good to have a
> general security mechanism for OSGi services I have created a JIRA for that
> (KARAF-2455) and noted that role-based security for the commands can be
> built on top of this (KARAF-2442).
>
> Cheers,
>
> David
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Since I think the general consensus here is that it would be good to have a
general security mechanism for OSGi services I have created a JIRA for that
(KARAF-2455) and noted that role-based security for the commands can be
built on top of this (KARAF-2442).

Cheers,

David

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Good point David.

Regards
JB

On 08/23/2013 01:00 PM, David Bosschaert wrote:
> That may be true for the Karaf MBeans but there are also other MBeans in
> the system. For example ones provided by the JVM. As an example take the
> MBean with the following object name: connector:name=rmi
> It is registered by the JVM and not through OSGi services and has a few
> operations (start(), stop()). By purely having the ACLs go through the
> service registry model you would not be able to prevent anyone from calling
> stop() on that mbean...
>
> It's just an example. Another example would be when an OSGi bundle
> registers MBeans directly (not through the WhiteBoard pattern). With the
> approach I suggest in KARAF-2435 you can secure any JMX operation,
> regardless of whether it's implemented as an OSGi service or not...
>
> Cheers,
>
> David
>
> On 23 August 2013 11:43, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> Hi guys,
>>
>> @David, on trunk (3.0.0-SNAPSHOT), Karaf uses Aries JMX for MBean
>> registration. Aries JMX looks up for MBeans exposed as OSGi services. So I
>> think we can leverage it.
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>>
>> On 08/23/2013 10:41 AM, David Bosschaert wrote:
>>
>>> Hi Christian,
>>>
>>> On 22 August 2013 23:14, Christian Schneider <ch...@die-schneider.net>**
>>> wrote:
>>>
>>>   Sounds great. I have not yet looked into it in detail but the concept
>>>> sounds decent.
>>>>
>>>> One thing you should keep in mind is to make the authorization
>>>> exchangeable. For example at Talend we provide an xacml based pdp. So it
>>>> would be great to have a hook wehere we can plug this in to
>>>> do the auth decisions. Personally I am not a fan of xacml but this shows
>>>> that different organizations would probably like to treat this
>>>> differently.
>>>>
>>>>
>>> What I did provides the authorization roles completely through
>>> ConfigAdmin.
>>> Which is pluggable in a number of ways: in Karaf we use the Felix Config
>>> admin which allows the registration of additional configuration providers.
>>> You can also replace the Config Admin Service itself to provide the info
>>> from another place...
>>> I guess we can always add more pluggability if that's needed.
>>>
>>>
>>>   The way round your aproach sounds much more maintainable than xacml. So
>>>> it
>>>> might even be interesting to attach a pdp to your authorization impl :-)
>>>>
>>>>
>>> :)
>>>
>>>
>>>   I have one other idea. How about doing the authorization for jmx and
>>>> commands only on the service level? At least in karaf 3 both use the same
>>>> services so securing only the service instead of jmx and commands would
>>>> reduce the number of config settings needed.
>>>>
>>>> For example:
>>>> jmx: featureJMXBean.install(****feature)
>>>>
>>>> command: feature:install <feature>
>>>>
>>>> Both would be secured by simply securing the FeatureService.
>>>>
>>>>
>>> The problem with this is that there are still JMX APIs that aren't
>>> provided
>>> as OSGi services so that would leave a pretty big hole in the security if
>>> you ask me...
>>> For those cases where a single Service covers both JMX and the console we
>>> could use a single security point (that would be just a matter of
>>> configuring it that way), but I think that we still need the direct JMX
>>> security to make sure people can't do any damage through any of the
>>> non-OSGi-Service MBeans...
>>>
>>>
>>>   One thing I am not sure about btw. is doing too much magic behind the
>>>> scenes. Like the config admin config you described that causes other
>>>> configs to be created on the fly. Perhaps we find a simpler model that
>>>> also
>>>> works. Currently I do not have a good idea how to handle it though.
>>>>
>>>>
>>> I agree. We need to find the balance between simplicity and ease-of-use.
>>> If
>>> you think of a simpler way without configuration generation that doesn't
>>> make the thing horrilbly hard to use for commands I'd love to hear it.
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

That may be true for the Karaf MBeans but there are also other MBeans in
the system. For example ones provided by the JVM. As an example take the
MBean with the following object name: connector:name=rmi
It is registered by the JVM and not through OSGi services and has a few
operations (start(), stop()). By purely having the ACLs go through the
service registry model you would not be able to prevent anyone from calling
stop() on that mbean...

It's just an example. Another example would be when an OSGi bundle
registers MBeans directly (not through the WhiteBoard pattern). With the
approach I suggest in KARAF-2435 you can secure any JMX operation,
regardless of whether it's implemented as an OSGi service or not...

Cheers,

David

On 23 August 2013 11:43, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Hi guys,
>
> @David, on trunk (3.0.0-SNAPSHOT), Karaf uses Aries JMX for MBean
> registration. Aries JMX looks up for MBeans exposed as OSGi services. So I
> think we can leverage it.
>
> WDYT ?
>
> Regards
> JB
>
>
> On 08/23/2013 10:41 AM, David Bosschaert wrote:
>
>> Hi Christian,
>>
>> On 22 August 2013 23:14, Christian Schneider <ch...@die-schneider.net>**
>> wrote:
>>
>>  Sounds great. I have not yet looked into it in detail but the concept
>>> sounds decent.
>>>
>>> One thing you should keep in mind is to make the authorization
>>> exchangeable. For example at Talend we provide an xacml based pdp. So it
>>> would be great to have a hook wehere we can plug this in to
>>> do the auth decisions. Personally I am not a fan of xacml but this shows
>>> that different organizations would probably like to treat this
>>> differently.
>>>
>>>
>> What I did provides the authorization roles completely through
>> ConfigAdmin.
>> Which is pluggable in a number of ways: in Karaf we use the Felix Config
>> admin which allows the registration of additional configuration providers.
>> You can also replace the Config Admin Service itself to provide the info
>> from another place...
>> I guess we can always add more pluggability if that's needed.
>>
>>
>>  The way round your aproach sounds much more maintainable than xacml. So
>>> it
>>> might even be interesting to attach a pdp to your authorization impl :-)
>>>
>>>
>> :)
>>
>>
>>  I have one other idea. How about doing the authorization for jmx and
>>> commands only on the service level? At least in karaf 3 both use the same
>>> services so securing only the service instead of jmx and commands would
>>> reduce the number of config settings needed.
>>>
>>> For example:
>>> jmx: featureJMXBean.install(****feature)
>>>
>>> command: feature:install <feature>
>>>
>>> Both would be secured by simply securing the FeatureService.
>>>
>>>
>> The problem with this is that there are still JMX APIs that aren't
>> provided
>> as OSGi services so that would leave a pretty big hole in the security if
>> you ask me...
>> For those cases where a single Service covers both JMX and the console we
>> could use a single security point (that would be just a matter of
>> configuring it that way), but I think that we still need the direct JMX
>> security to make sure people can't do any damage through any of the
>> non-OSGi-Service MBeans...
>>
>>
>>  One thing I am not sure about btw. is doing too much magic behind the
>>> scenes. Like the config admin config you described that causes other
>>> configs to be created on the fly. Perhaps we find a simpler model that
>>> also
>>> works. Currently I do not have a good idea how to handle it though.
>>>
>>>
>> I agree. We need to find the balance between simplicity and ease-of-use.
>> If
>> you think of a simpler way without configuration generation that doesn't
>> make the thing horrilbly hard to use for commands I'd love to hear it.
>>
>> Cheers,
>>
>> David
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi guys,

@David, on trunk (3.0.0-SNAPSHOT), Karaf uses Aries JMX for MBean 
registration. Aries JMX looks up for MBeans exposed as OSGi services. So 
I think we can leverage it.

WDYT ?

Regards
JB

On 08/23/2013 10:41 AM, David Bosschaert wrote:
> Hi Christian,
>
> On 22 August 2013 23:14, Christian Schneider <ch...@die-schneider.net>wrote:
>
>> Sounds great. I have not yet looked into it in detail but the concept
>> sounds decent.
>>
>> One thing you should keep in mind is to make the authorization
>> exchangeable. For example at Talend we provide an xacml based pdp. So it
>> would be great to have a hook wehere we can plug this in to
>> do the auth decisions. Personally I am not a fan of xacml but this shows
>> that different organizations would probably like to treat this differently.
>>
>
> What I did provides the authorization roles completely through ConfigAdmin.
> Which is pluggable in a number of ways: in Karaf we use the Felix Config
> admin which allows the registration of additional configuration providers.
> You can also replace the Config Admin Service itself to provide the info
> from another place...
> I guess we can always add more pluggability if that's needed.
>
>
>> The way round your aproach sounds much more maintainable than xacml. So it
>> might even be interesting to attach a pdp to your authorization impl :-)
>>
>
> :)
>
>
>> I have one other idea. How about doing the authorization for jmx and
>> commands only on the service level? At least in karaf 3 both use the same
>> services so securing only the service instead of jmx and commands would
>> reduce the number of config settings needed.
>>
>> For example:
>> jmx: featureJMXBean.install(**feature)
>> command: feature:install <feature>
>>
>> Both would be secured by simply securing the FeatureService.
>>
>
> The problem with this is that there are still JMX APIs that aren't provided
> as OSGi services so that would leave a pretty big hole in the security if
> you ask me...
> For those cases where a single Service covers both JMX and the console we
> could use a single security point (that would be just a matter of
> configuring it that way), but I think that we still need the direct JMX
> security to make sure people can't do any damage through any of the
> non-OSGi-Service MBeans...
>
>
>> One thing I am not sure about btw. is doing too much magic behind the
>> scenes. Like the config admin config you described that causes other
>> configs to be created on the fly. Perhaps we find a simpler model that also
>> works. Currently I do not have a good idea how to handle it though.
>>
>
> I agree. We need to find the balance between simplicity and ease-of-use. If
> you think of a simpler way without configuration generation that doesn't
> make the thing horrilbly hard to use for commands I'd love to hear it.
>
> Cheers,
>
> David
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Hi Christian,

On 22 August 2013 23:14, Christian Schneider <ch...@die-schneider.net>wrote:

> Sounds great. I have not yet looked into it in detail but the concept
> sounds decent.
>
> One thing you should keep in mind is to make the authorization
> exchangeable. For example at Talend we provide an xacml based pdp. So it
> would be great to have a hook wehere we can plug this in to
> do the auth decisions. Personally I am not a fan of xacml but this shows
> that different organizations would probably like to treat this differently.
>

What I did provides the authorization roles completely through ConfigAdmin.
Which is pluggable in a number of ways: in Karaf we use the Felix Config
admin which allows the registration of additional configuration providers.
You can also replace the Config Admin Service itself to provide the info
from another place...
I guess we can always add more pluggability if that's needed.


> The way round your aproach sounds much more maintainable than xacml. So it
> might even be interesting to attach a pdp to your authorization impl :-)
>

:)


> I have one other idea. How about doing the authorization for jmx and
> commands only on the service level? At least in karaf 3 both use the same
> services so securing only the service instead of jmx and commands would
> reduce the number of config settings needed.
>
> For example:
> jmx: featureJMXBean.install(**feature)
> command: feature:install <feature>
>
> Both would be secured by simply securing the FeatureService.
>

The problem with this is that there are still JMX APIs that aren't provided
as OSGi services so that would leave a pretty big hole in the security if
you ask me...
For those cases where a single Service covers both JMX and the console we
could use a single security point (that would be just a matter of
configuring it that way), but I think that we still need the direct JMX
security to make sure people can't do any damage through any of the
non-OSGi-Service MBeans...


> One thing I am not sure about btw. is doing too much magic behind the
> scenes. Like the config admin config you described that causes other
> configs to be created on the fly. Perhaps we find a simpler model that also
> works. Currently I do not have a good idea how to handle it though.
>

I agree. We need to find the balance between simplicity and ease-of-use. If
you think of a simpler way without configuration generation that doesn't
make the thing horrilbly hard to use for commands I'd love to hear it.

Cheers,

David

Re: Some thoughts around adding security for Karaf Shell Commands

[Christian Schneider <ch...@die-schneider.net>]

Sounds great. I have not yet looked into it in detail but the concept 
sounds decent.

One thing you should keep in mind is to make the authorization 
exchangeable. For example at Talend we provide an xacml based pdp. So it 
would be great to have a hook wehere we can plug this in to
do the auth decisions. Personally I am not a fan of xacml but this shows 
that different organizations would probably like to treat this differently.

The way round your aproach sounds much more maintainable than xacml. So 
it might even be interesting to attach a pdp to your authorization impl :-)

I have one other idea. How about doing the authorization for jmx and 
commands only on the service level? At least in karaf 3 both use the 
same services so securing only the service instead of jmx and commands 
would reduce the number of config settings needed.

For example:
jmx: featureJMXBean.install(feature)
command: feature:install <feature>

Both would be secured by simply securing the FeatureService.

One thing I am not sure about btw. is doing too much magic behind the 
scenes. Like the config admin config you described that causes other 
configs to be created on the fly. Perhaps we find a simpler model that also
works. Currently I do not have a good idea how to handle it though.

Christian

Am 22.08.2013 17:07, schrieb David Bosschaert:
> Hi all,
>
> As suggested by Christian, I started looking at adding role-based access to
> OSGi services in general (in Karaf) and applying this to the Karaf commands.
> At this point I have something that kinda works. It proxies services for
> service consumers using service registry hooks and on invocation checks
> that the Subject associated with the current Access Control Context has the
> right roles. If not it blocks the service invocation by throwing a
> SecurityException.
>
> Not all services are secured this way, there is a new property in
> etc/system.properties that selects what services are processed this way
> using a simple OSGi service filter. To apply it to the shell commands it is
> set to the following:
>    karaf.secured.services=(&(osgi.command.scope=*)(osgi.command.function=*))
>
> The actual ACLs for the secured services are defined using ConfigAdmin in a
> way that's pretty much identical to what I did for the JMX acls in
> KARAF-2435, except that the PID doesn't matter. The configuration is
> matched with a service on a 'service.guard' property. The other entries
> match method names of the service. They can also match values passed in (as
> you can do with JMX), so you can define different roles for doit("foo") and
> doit("bar"). An example configuration could look like this:
>    service.guard = (objectClass=org.acme.TestServiceAPI)
>    doit = admin, viewer
>    doit["foo"] = admin
>
> So the next thing I did was look at whether this could be applied to the
> shell commands. The problem was that every little command is a separate
> service so this would potentially be a lot of configuration files for the
> administrator to maintain. You really want to define the ACLs for a single
> scope in a single configuration file, something like this (for the bundle
> scope):
>    install = manager
>    start = manager
>    list = manager, viewer
>    stop = manager
>    stop[/.*0.*/] = admin # only admin can stop the framework
>    uninstall = admin
> To fit with the general service ACL model this would have to be 5 different
> configuration files (one for each command). I thought that that was not
> very user friendly. Therefore I came up with a mechanism that accepts
> ConfigAdmin configuration for commands in the same scope like the above and
> then generates additional ConfigAdmin configuration on the fly that
> conforms to the general service ACL form.
>
> With that, enabled... let's say I'm logged in as a 'manager', with the
> above example configuration for the bundle scope, the it has the following
> effect:
>    karaf@root()> stop 50
>    # works
>    karaf@root()> stop 0
>    Error executing command: Insufficient credentials.
> Which is pretty much what I wanted to achieve :)
>
> So basically what we have here is a combination of two things:
> 1. Modification of service registrations to add a roles property which is
> then used by the CommandProcessor to only show the commands that the user
> associated with the active console can potentially execute (it could still
> reject commands based on arguments passed in).
> 2. Proxying of services (including shell command services) that check that
> the Subject associated with the current AccessControlContext has the right
> roles to make this invocation.
> The role-checking is still done outside of the service implementations. The
> actual services being secured don't need to change their code.
>
> You can see my experimental implementation at my branch here:
> https://github.com/bosschaert/karaf/commit/2668b88a7ddfb1ba93e7e732884734ff7dc0d1a3
> That branch is not finished (cleanup, tests terribly lacking, no
> optimization) and some things could be made a little more user friendly,
> but it contains the general idea... If people are happy with the general
> idea I can focus a little on tiding it up...
>
> Thoughts anyone?
>
> David
>
> On 19 August 2013 10:56, David Bosschaert <da...@gmail.com>wrote:
>
>> Hi Christian,
>>
>> On 19 August 2013 10:29, Christian Schneider <ch...@die-schneider.net>wrote:
>>
>>> The idea was to use Shiro to establish a kind of security context in a
>>> thread local. Your approach of using Subject.doas might be the better
>>> alternative though.
>>>   In any case we should recommend one standard approach to establish the
>>> security context. Perhaps we could even allow both and have adapters to
>>> establish one context from another.
>>
>> Yep, this needs to be standard.
>>
>>
>>>   On 08/15/2013 10:16 PM, Christian Schneider wrote:
>>>>>   I like the idea of adding permissions to the commands. I wonder though
>>>>>> if this is perhaps a more general problem that not only affects
>>>>>> commands.
>>>>>>
>>>>>> So how about adding a generic permission check for services? For
>>>>>> example
>>>>>> I would like to use the @RolesAllowed annotation to couple roles or
>>>>>> permissions with service methods.
>>>>>> A service registry hook could then check that the caller has the
>>>>>> permission before allowing the call. Of course there could be other
>>>>>> additional way of adding this information like the service properties
>>>>>> you mentioned.
>>>>>>
>>>>>>   I'm not sure I like the annotation approach. One of the things that I
>>>> would
>>>> like to enable is for customers to change the roles associated with
>>>> operations/service invocations afterwards, simply because the roles
>>>> chosen
>>>> by the developer may not match up with the roles mappings of all
>>>> organizations. With an annotation approach you'd have to modify the code
>>>> and recompile it when you want to change them. I prefer to use OSGi
>>>> ConfigAdmin for that since it completely decouples this information from
>>>> the code and can easily be modified later...
>>>>
>>>> We should also provide a generic way to attach authentication
>>>>
>>> I think there could be three levels of external configurability:
>>>
>>> 1. You could use annotations with roles like
>>> @RolesAllowed("admin")
>>> public void deleteUser(...);
>>>
>>> 2. You could use annotations to store permissions
>>> @RolesAllowed("Userservice.**deleteUser")
>>> public void deleteUser(...);
>>>
>>> Then the mapping to roles could be done by using groups in the simplest
>>> form. group UserService.deleteUser: admin, ...
>>>
>>> 3. You could completely externalize the decision. In this case a Policy
>>> Decision Point approach could make sense.
>>> You extract the meta information of a service call, give it to a pdp and
>>> get back an authorization decision.
>>
>>
>> I would favor having just option 3. I can see that option 2 provides some
>> form of indirection, but you still need to modify the service code to add
>> the annotation in the first place. That might be ok for services that have
>> their code in the Karaf codebase, but for outside services it would be
>> pretty much impossible.
>>
>> I would rather have a clear single way of configuring this so that it's
>> very clear what the definition is - if a security guy wants to figure out
>> what roles are needed for options 1 & 2 (s)he needs to have access to the
>> source to read how the annotation was declared, or otherwise rely on
>> documentation, which you are never sure is actually in sync with the code.
>>
>> If we'd opt for a combined annotation+external approach it's still quite
>> hard to get a full overview of what roles are required to invoke what if
>> you want to understand that... Hence I would simply go for having just
>> option 3 and keep everything in one place.
>>
>>
>>
>>>   information to a thread that calls a service. I tought about using
>>>>>> apache shiro for this but I am not sure if it is universal enough.
>>>>>>
>>>>>>   I don't understand why you need Shiro for this.
>>>> Isn't javax.security.auth.Subject.**doAs() the standard way to do this?
>>>>
>>> Probably it is. How does this work internally? Does it also use a thread
>>> local? How  does it work if you spawn a new thread using an executor or
>>> similar?
>>> I think we should do some examples to see how it works in practice.
>>>
>>
>> Re Subject.doAs(). The Subject would be configured via JAAS to contain the
>> appropriate roles for the current user, as we do today in Karaf (although
>> you should be able to configure Shiro to provide this info)...
>> Once you're inside a piece of code that is executed via Subject.doAs()
>> (which could be in a different thread) you can do:
>>
>>    AccessControlContext acc = AccessController.getContext();
>>    Subject subject = Subject.getSubject(acc);
>> At this point you can get all the Principals from the subject, e.g. all
>> the roles:
>>    Set<RolePrincipal> roles = subject.getPrincipals(RolePrincipal.class);
>>
>> This is all plain standard J2SE code, no library dependencies...
>>
>> Cheers,
>>
>> David
>>


-- 
  
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Yeah, but it gives good indication about what you want to do ;)

Cheers
JB

On 08/22/2013 07:47 PM, David Bosschaert wrote:
> Thanks JB,
>
> Don't take the code on my github commit too literally ;) I'm more wondering
> whether people like the approach in general. As I said, the code itself is
> quite incomplete and I realized that I can simplify it too (I should be
> able to collapse the 2 sets of Service Registry Hooks into a single set).
> I'm sure I'll find loads of things to improve when I write unit tests as
> well.
>
> Cheers,
>
> David
>
> On 22 August 2013 18:37, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> Hi David,
>>
>> again it sounds good, and it's what I had in mind.
>>
>> Before provide a more complete feedback, let me take a look on your github.
>>
>> Thanks anyway !
>>
>> Regards
>> JB
>>
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Thanks JB,

Don't take the code on my github commit too literally ;) I'm more wondering
whether people like the approach in general. As I said, the code itself is
quite incomplete and I realized that I can simplify it too (I should be
able to collapse the 2 sets of Service Registry Hooks into a single set).
I'm sure I'll find loads of things to improve when I write unit tests as
well.

Cheers,

David

On 22 August 2013 18:37, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Hi David,
>
> again it sounds good, and it's what I had in mind.
>
> Before provide a more complete feedback, let me take a look on your github.
>
> Thanks anyway !
>
> Regards
> JB
>
>

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi David,

again it sounds good, and it's what I had in mind.

Before provide a more complete feedback, let me take a look on your github.

Thanks anyway !

Regards
JB

On 08/22/2013 05:07 PM, David Bosschaert wrote:
> Hi all,
>
> As suggested by Christian, I started looking at adding role-based access to
> OSGi services in general (in Karaf) and applying this to the Karaf commands.
> At this point I have something that kinda works. It proxies services for
> service consumers using service registry hooks and on invocation checks
> that the Subject associated with the current Access Control Context has the
> right roles. If not it blocks the service invocation by throwing a
> SecurityException.
>
> Not all services are secured this way, there is a new property in
> etc/system.properties that selects what services are processed this way
> using a simple OSGi service filter. To apply it to the shell commands it is
> set to the following:
>    karaf.secured.services=(&(osgi.command.scope=*)(osgi.command.function=*))
>
> The actual ACLs for the secured services are defined using ConfigAdmin in a
> way that's pretty much identical to what I did for the JMX acls in
> KARAF-2435, except that the PID doesn't matter. The configuration is
> matched with a service on a 'service.guard' property. The other entries
> match method names of the service. They can also match values passed in (as
> you can do with JMX), so you can define different roles for doit("foo") and
> doit("bar"). An example configuration could look like this:
>    service.guard = (objectClass=org.acme.TestServiceAPI)
>    doit = admin, viewer
>    doit["foo"] = admin
>
> So the next thing I did was look at whether this could be applied to the
> shell commands. The problem was that every little command is a separate
> service so this would potentially be a lot of configuration files for the
> administrator to maintain. You really want to define the ACLs for a single
> scope in a single configuration file, something like this (for the bundle
> scope):
>    install = manager
>    start = manager
>    list = manager, viewer
>    stop = manager
>    stop[/.*0.*/] = admin # only admin can stop the framework
>    uninstall = admin
> To fit with the general service ACL model this would have to be 5 different
> configuration files (one for each command). I thought that that was not
> very user friendly. Therefore I came up with a mechanism that accepts
> ConfigAdmin configuration for commands in the same scope like the above and
> then generates additional ConfigAdmin configuration on the fly that
> conforms to the general service ACL form.
>
> With that, enabled... let's say I'm logged in as a 'manager', with the
> above example configuration for the bundle scope, the it has the following
> effect:
>    karaf@root()> stop 50
>    # works
>    karaf@root()> stop 0
>    Error executing command: Insufficient credentials.
> Which is pretty much what I wanted to achieve :)
>
> So basically what we have here is a combination of two things:
> 1. Modification of service registrations to add a roles property which is
> then used by the CommandProcessor to only show the commands that the user
> associated with the active console can potentially execute (it could still
> reject commands based on arguments passed in).
> 2. Proxying of services (including shell command services) that check that
> the Subject associated with the current AccessControlContext has the right
> roles to make this invocation.
> The role-checking is still done outside of the service implementations. The
> actual services being secured don't need to change their code.
>
> You can see my experimental implementation at my branch here:
> https://github.com/bosschaert/karaf/commit/2668b88a7ddfb1ba93e7e732884734ff7dc0d1a3
> That branch is not finished (cleanup, tests terribly lacking, no
> optimization) and some things could be made a little more user friendly,
> but it contains the general idea... If people are happy with the general
> idea I can focus a little on tiding it up...
>
> Thoughts anyone?
>
> David
>
> On 19 August 2013 10:56, David Bosschaert <da...@gmail.com>wrote:
>
>> Hi Christian,
>>
>> On 19 August 2013 10:29, Christian Schneider <ch...@die-schneider.net>wrote:
>>
>>> The idea was to use Shiro to establish a kind of security context in a
>>> thread local. Your approach of using Subject.doas might be the better
>>> alternative though.
>>>   In any case we should recommend one standard approach to establish the
>>> security context. Perhaps we could even allow both and have adapters to
>>> establish one context from another.
>>
>>
>> Yep, this needs to be standard.
>>
>>
>>>   On 08/15/2013 10:16 PM, Christian Schneider wrote:
>>>>>
>>>>>   I like the idea of adding permissions to the commands. I wonder though
>>>>>> if this is perhaps a more general problem that not only affects
>>>>>> commands.
>>>>>>
>>>>>> So how about adding a generic permission check for services? For
>>>>>> example
>>>>>> I would like to use the @RolesAllowed annotation to couple roles or
>>>>>> permissions with service methods.
>>>>>> A service registry hook could then check that the caller has the
>>>>>> permission before allowing the call. Of course there could be other
>>>>>> additional way of adding this information like the service properties
>>>>>> you mentioned.
>>>>>>
>>>>>>   I'm not sure I like the annotation approach. One of the things that I
>>>> would
>>>> like to enable is for customers to change the roles associated with
>>>> operations/service invocations afterwards, simply because the roles
>>>> chosen
>>>> by the developer may not match up with the roles mappings of all
>>>> organizations. With an annotation approach you'd have to modify the code
>>>> and recompile it when you want to change them. I prefer to use OSGi
>>>> ConfigAdmin for that since it completely decouples this information from
>>>> the code and can easily be modified later...
>>>>
>>>> We should also provide a generic way to attach authentication
>>>>
>>> I think there could be three levels of external configurability:
>>>
>>> 1. You could use annotations with roles like
>>> @RolesAllowed("admin")
>>> public void deleteUser(...);
>>>
>>> 2. You could use annotations to store permissions
>>> @RolesAllowed("Userservice.**deleteUser")
>>> public void deleteUser(...);
>>>
>>> Then the mapping to roles could be done by using groups in the simplest
>>> form. group UserService.deleteUser: admin, ...
>>>
>>> 3. You could completely externalize the decision. In this case a Policy
>>> Decision Point approach could make sense.
>>> You extract the meta information of a service call, give it to a pdp and
>>> get back an authorization decision.
>>
>>
>>
>> I would favor having just option 3. I can see that option 2 provides some
>> form of indirection, but you still need to modify the service code to add
>> the annotation in the first place. That might be ok for services that have
>> their code in the Karaf codebase, but for outside services it would be
>> pretty much impossible.
>>
>> I would rather have a clear single way of configuring this so that it's
>> very clear what the definition is - if a security guy wants to figure out
>> what roles are needed for options 1 & 2 (s)he needs to have access to the
>> source to read how the annotation was declared, or otherwise rely on
>> documentation, which you are never sure is actually in sync with the code.
>>
>> If we'd opt for a combined annotation+external approach it's still quite
>> hard to get a full overview of what roles are required to invoke what if
>> you want to understand that... Hence I would simply go for having just
>> option 3 and keep everything in one place.
>>
>>
>>
>>>   information to a thread that calls a service. I tought about using
>>>>>> apache shiro for this but I am not sure if it is universal enough.
>>>>>>
>>>>>>   I don't understand why you need Shiro for this.
>>>> Isn't javax.security.auth.Subject.**doAs() the standard way to do this?
>>>>
>>> Probably it is. How does this work internally? Does it also use a thread
>>> local? How  does it work if you spawn a new thread using an executor or
>>> similar?
>>> I think we should do some examples to see how it works in practice.
>>>
>>
>>
>> Re Subject.doAs(). The Subject would be configured via JAAS to contain the
>> appropriate roles for the current user, as we do today in Karaf (although
>> you should be able to configure Shiro to provide this info)...
>> Once you're inside a piece of code that is executed via Subject.doAs()
>> (which could be in a different thread) you can do:
>>
>>    AccessControlContext acc = AccessController.getContext();
>>    Subject subject = Subject.getSubject(acc);
>> At this point you can get all the Principals from the subject, e.g. all
>> the roles:
>>    Set<RolePrincipal> roles = subject.getPrincipals(RolePrincipal.class);
>>
>> This is all plain standard J2SE code, no library dependencies...
>>
>> Cheers,
>>
>> David
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Hi all,

As suggested by Christian, I started looking at adding role-based access to
OSGi services in general (in Karaf) and applying this to the Karaf commands.
At this point I have something that kinda works. It proxies services for
service consumers using service registry hooks and on invocation checks
that the Subject associated with the current Access Control Context has the
right roles. If not it blocks the service invocation by throwing a
SecurityException.

Not all services are secured this way, there is a new property in
etc/system.properties that selects what services are processed this way
using a simple OSGi service filter. To apply it to the shell commands it is
set to the following:
  karaf.secured.services=(&(osgi.command.scope=*)(osgi.command.function=*))

The actual ACLs for the secured services are defined using ConfigAdmin in a
way that's pretty much identical to what I did for the JMX acls in
KARAF-2435, except that the PID doesn't matter. The configuration is
matched with a service on a 'service.guard' property. The other entries
match method names of the service. They can also match values passed in (as
you can do with JMX), so you can define different roles for doit("foo") and
doit("bar"). An example configuration could look like this:
  service.guard = (objectClass=org.acme.TestServiceAPI)
  doit = admin, viewer
  doit["foo"] = admin

So the next thing I did was look at whether this could be applied to the
shell commands. The problem was that every little command is a separate
service so this would potentially be a lot of configuration files for the
administrator to maintain. You really want to define the ACLs for a single
scope in a single configuration file, something like this (for the bundle
scope):
  install = manager
  start = manager
  list = manager, viewer
  stop = manager
  stop[/.*0.*/] = admin # only admin can stop the framework
  uninstall = admin
To fit with the general service ACL model this would have to be 5 different
configuration files (one for each command). I thought that that was not
very user friendly. Therefore I came up with a mechanism that accepts
ConfigAdmin configuration for commands in the same scope like the above and
then generates additional ConfigAdmin configuration on the fly that
conforms to the general service ACL form.

With that, enabled... let's say I'm logged in as a 'manager', with the
above example configuration for the bundle scope, the it has the following
effect:
  karaf@root()> stop 50
  # works
  karaf@root()> stop 0
  Error executing command: Insufficient credentials.
Which is pretty much what I wanted to achieve :)

So basically what we have here is a combination of two things:
1. Modification of service registrations to add a roles property which is
then used by the CommandProcessor to only show the commands that the user
associated with the active console can potentially execute (it could still
reject commands based on arguments passed in).
2. Proxying of services (including shell command services) that check that
the Subject associated with the current AccessControlContext has the right
roles to make this invocation.
The role-checking is still done outside of the service implementations. The
actual services being secured don't need to change their code.

You can see my experimental implementation at my branch here:
https://github.com/bosschaert/karaf/commit/2668b88a7ddfb1ba93e7e732884734ff7dc0d1a3
That branch is not finished (cleanup, tests terribly lacking, no
optimization) and some things could be made a little more user friendly,
but it contains the general idea... If people are happy with the general
idea I can focus a little on tiding it up...

Thoughts anyone?

David

On 19 August 2013 10:56, David Bosschaert <da...@gmail.com>wrote:

> Hi Christian,
>
> On 19 August 2013 10:29, Christian Schneider <ch...@die-schneider.net>wrote:
>
>> The idea was to use Shiro to establish a kind of security context in a
>> thread local. Your approach of using Subject.doas might be the better
>> alternative though.
>>  In any case we should recommend one standard approach to establish the
>> security context. Perhaps we could even allow both and have adapters to
>> establish one context from another.
>
>
> Yep, this needs to be standard.
>
>
>>  On 08/15/2013 10:16 PM, Christian Schneider wrote:
>>>>
>>>>  I like the idea of adding permissions to the commands. I wonder though
>>>>> if this is perhaps a more general problem that not only affects
>>>>> commands.
>>>>>
>>>>> So how about adding a generic permission check for services? For
>>>>> example
>>>>> I would like to use the @RolesAllowed annotation to couple roles or
>>>>> permissions with service methods.
>>>>> A service registry hook could then check that the caller has the
>>>>> permission before allowing the call. Of course there could be other
>>>>> additional way of adding this information like the service properties
>>>>> you mentioned.
>>>>>
>>>>>  I'm not sure I like the annotation approach. One of the things that I
>>> would
>>> like to enable is for customers to change the roles associated with
>>> operations/service invocations afterwards, simply because the roles
>>> chosen
>>> by the developer may not match up with the roles mappings of all
>>> organizations. With an annotation approach you'd have to modify the code
>>> and recompile it when you want to change them. I prefer to use OSGi
>>> ConfigAdmin for that since it completely decouples this information from
>>> the code and can easily be modified later...
>>>
>>> We should also provide a generic way to attach authentication
>>>
>> I think there could be three levels of external configurability:
>>
>> 1. You could use annotations with roles like
>> @RolesAllowed("admin")
>> public void deleteUser(...);
>>
>> 2. You could use annotations to store permissions
>> @RolesAllowed("Userservice.**deleteUser")
>> public void deleteUser(...);
>>
>> Then the mapping to roles could be done by using groups in the simplest
>> form. group UserService.deleteUser: admin, ...
>>
>> 3. You could completely externalize the decision. In this case a Policy
>> Decision Point approach could make sense.
>> You extract the meta information of a service call, give it to a pdp and
>> get back an authorization decision.
>
>
>
> I would favor having just option 3. I can see that option 2 provides some
> form of indirection, but you still need to modify the service code to add
> the annotation in the first place. That might be ok for services that have
> their code in the Karaf codebase, but for outside services it would be
> pretty much impossible.
>
> I would rather have a clear single way of configuring this so that it's
> very clear what the definition is - if a security guy wants to figure out
> what roles are needed for options 1 & 2 (s)he needs to have access to the
> source to read how the annotation was declared, or otherwise rely on
> documentation, which you are never sure is actually in sync with the code.
>
> If we'd opt for a combined annotation+external approach it's still quite
> hard to get a full overview of what roles are required to invoke what if
> you want to understand that... Hence I would simply go for having just
> option 3 and keep everything in one place.
>
>
>
>>  information to a thread that calls a service. I tought about using
>>>>> apache shiro for this but I am not sure if it is universal enough.
>>>>>
>>>>>  I don't understand why you need Shiro for this.
>>> Isn't javax.security.auth.Subject.**doAs() the standard way to do this?
>>>
>> Probably it is. How does this work internally? Does it also use a thread
>> local? How  does it work if you spawn a new thread using an executor or
>> similar?
>> I think we should do some examples to see how it works in practice.
>>
>
>
> Re Subject.doAs(). The Subject would be configured via JAAS to contain the
> appropriate roles for the current user, as we do today in Karaf (although
> you should be able to configure Shiro to provide this info)...
> Once you're inside a piece of code that is executed via Subject.doAs()
> (which could be in a different thread) you can do:
>
>   AccessControlContext acc = AccessController.getContext();
>   Subject subject = Subject.getSubject(acc);
> At this point you can get all the Principals from the subject, e.g. all
> the roles:
>   Set<RolePrincipal> roles = subject.getPrincipals(RolePrincipal.class);
>
> This is all plain standard J2SE code, no library dependencies...
>
> Cheers,
>
> David
>

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Hi Christian,

On 19 August 2013 10:29, Christian Schneider <ch...@die-schneider.net>wrote:

> The idea was to use Shiro to establish a kind of security context in a
> thread local. Your approach of using Subject.doas might be the better
> alternative though.
>  In any case we should recommend one standard approach to establish the
> security context. Perhaps we could even allow both and have adapters to
> establish one context from another.


Yep, this needs to be standard.


>  On 08/15/2013 10:16 PM, Christian Schneider wrote:
>>>
>>>  I like the idea of adding permissions to the commands. I wonder though
>>>> if this is perhaps a more general problem that not only affects
>>>> commands.
>>>>
>>>> So how about adding a generic permission check for services? For example
>>>> I would like to use the @RolesAllowed annotation to couple roles or
>>>> permissions with service methods.
>>>> A service registry hook could then check that the caller has the
>>>> permission before allowing the call. Of course there could be other
>>>> additional way of adding this information like the service properties
>>>> you mentioned.
>>>>
>>>>  I'm not sure I like the annotation approach. One of the things that I
>> would
>> like to enable is for customers to change the roles associated with
>> operations/service invocations afterwards, simply because the roles chosen
>> by the developer may not match up with the roles mappings of all
>> organizations. With an annotation approach you'd have to modify the code
>> and recompile it when you want to change them. I prefer to use OSGi
>> ConfigAdmin for that since it completely decouples this information from
>> the code and can easily be modified later...
>>
>> We should also provide a generic way to attach authentication
>>
> I think there could be three levels of external configurability:
>
> 1. You could use annotations with roles like
> @RolesAllowed("admin")
> public void deleteUser(...);
>
> 2. You could use annotations to store permissions
> @RolesAllowed("Userservice.**deleteUser")
> public void deleteUser(...);
>
> Then the mapping to roles could be done by using groups in the simplest
> form. group UserService.deleteUser: admin, ...
>
> 3. You could completely externalize the decision. In this case a Policy
> Decision Point approach could make sense.
> You extract the meta information of a service call, give it to a pdp and
> get back an authorization decision.



I would favor having just option 3. I can see that option 2 provides some
form of indirection, but you still need to modify the service code to add
the annotation in the first place. That might be ok for services that have
their code in the Karaf codebase, but for outside services it would be
pretty much impossible.

I would rather have a clear single way of configuring this so that it's
very clear what the definition is - if a security guy wants to figure out
what roles are needed for options 1 & 2 (s)he needs to have access to the
source to read how the annotation was declared, or otherwise rely on
documentation, which you are never sure is actually in sync with the code.

If we'd opt for a combined annotation+external approach it's still quite
hard to get a full overview of what roles are required to invoke what if
you want to understand that... Hence I would simply go for having just
option 3 and keep everything in one place.



>  information to a thread that calls a service. I tought about using
>>>> apache shiro for this but I am not sure if it is universal enough.
>>>>
>>>>  I don't understand why you need Shiro for this.
>> Isn't javax.security.auth.Subject.**doAs() the standard way to do this?
>>
> Probably it is. How does this work internally? Does it also use a thread
> local? How  does it work if you spawn a new thread using an executor or
> similar?
> I think we should do some examples to see how it works in practice.
>


Re Subject.doAs(). The Subject would be configured via JAAS to contain the
appropriate roles for the current user, as we do today in Karaf (although
you should be able to configure Shiro to provide this info)...
Once you're inside a piece of code that is executed via Subject.doAs()
(which could be in a different thread) you can do:

  AccessControlContext acc = AccessController.getContext();
  Subject subject = Subject.getSubject(acc);
At this point you can get all the Principals from the subject, e.g. all the
roles:
  Set<RolePrincipal> roles = subject.getPrincipals(RolePrincipal.class);

This is all plain standard J2SE code, no library dependencies...

Cheers,

David

Re: Some thoughts around adding security for Karaf Shell Commands

[Christian Schneider <ch...@die-schneider.net>]

On 19.08.2013 10:55, David Bosschaert wrote:
> Hi all,
>
> On 15 August 2013 21:23, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> OSGi already provides the security module for that, and it's what David
>> proposed (to "leverage" the services security).
>>
> Well AFAIK OSGi doesn't yet contain a general framework for
> allowing/disallowing the invocation of *existing* services based on
> Principals of the current user.
> So I actually agree with Cristian that this would indeed be a nice general
> feature. It should be possible to generalize my proposal so that it can be
> used for other purposes than just commands...
>
>
>> An extension with Shiro (expecially now that we have Pax Shiro ;)) is a
>> good idea.
>>
> That should be possible later, but I'd like to keep it as simple as
> possible for now. There is no need to use Shiro for this stuff, but I can
> see that people who already use Shiro like to have an integration.
>
The idea was to use Shiro to establish a kind of security context in a 
thread local. Your approach of using Subject.doas might be the better 
alternative though.
In any case we should recommend one standard approach to establish the 
security context. Perhaps we could even allow both and have adapters to 
establish one context from another.
>> On 08/15/2013 10:16 PM, Christian Schneider wrote:
>>
>>> I like the idea of adding permissions to the commands. I wonder though
>>> if this is perhaps a more general problem that not only affects commands.
>>>
>>> So how about adding a generic permission check for services? For example
>>> I would like to use the @RolesAllowed annotation to couple roles or
>>> permissions with service methods.
>>> A service registry hook could then check that the caller has the
>>> permission before allowing the call. Of course there could be other
>>> additional way of adding this information like the service properties
>>> you mentioned.
>>>
> I'm not sure I like the annotation approach. One of the things that I would
> like to enable is for customers to change the roles associated with
> operations/service invocations afterwards, simply because the roles chosen
> by the developer may not match up with the roles mappings of all
> organizations. With an annotation approach you'd have to modify the code
> and recompile it when you want to change them. I prefer to use OSGi
> ConfigAdmin for that since it completely decouples this information from
> the code and can easily be modified later...
>
> We should also provide a generic way to attach authentication
I think there could be three levels of external configurability:

1. You could use annotations with roles like
@RolesAllowed("admin")
public void deleteUser(...);

2. You could use annotations to store permissions
@RolesAllowed("Userservice.deleteUser")
public void deleteUser(...);

Then the mapping to roles could be done by using groups in the simplest 
form. group UserService.deleteUser: admin, ...

3. You could completely externalize the decision. In this case a Policy 
Decision Point approach could make sense.
You extract the meta information of a service call, give it to a pdp and 
get back an authorization decision.



>>> information to a thread that calls a service. I tought about using
>>> apache shiro for this but I am not sure if it is universal enough.
>>>
> I don't understand why you need Shiro for this.
> Isn't javax.security.auth.Subject.doAs() the standard way to do this?
Probably it is. How does this work internally? Does it also use a thread 
local? How  does it work if you spawn a new thread using an executor or 
similar?
I think we should do some examples to see how it works in practice.

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[David Bosschaert <da...@gmail.com>]

Hi all,

On 15 August 2013 21:23, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> OSGi already provides the security module for that, and it's what David
> proposed (to "leverage" the services security).
>

Well AFAIK OSGi doesn't yet contain a general framework for
allowing/disallowing the invocation of *existing* services based on
Principals of the current user.
So I actually agree with Cristian that this would indeed be a nice general
feature. It should be possible to generalize my proposal so that it can be
used for other purposes than just commands...


> An extension with Shiro (expecially now that we have Pax Shiro ;)) is a
> good idea.
>

That should be possible later, but I'd like to keep it as simple as
possible for now. There is no need to use Shiro for this stuff, but I can
see that people who already use Shiro like to have an integration.


>
> On 08/15/2013 10:16 PM, Christian Schneider wrote:
>
>> I like the idea of adding permissions to the commands. I wonder though
>> if this is perhaps a more general problem that not only affects commands.
>>
>> So how about adding a generic permission check for services? For example
>> I would like to use the @RolesAllowed annotation to couple roles or
>> permissions with service methods.
>> A service registry hook could then check that the caller has the
>> permission before allowing the call. Of course there could be other
>> additional way of adding this information like the service properties
>> you mentioned.
>>
>
I'm not sure I like the annotation approach. One of the things that I would
like to enable is for customers to change the roles associated with
operations/service invocations afterwards, simply because the roles chosen
by the developer may not match up with the roles mappings of all
organizations. With an annotation approach you'd have to modify the code
and recompile it when you want to change them. I prefer to use OSGi
ConfigAdmin for that since it completely decouples this information from
the code and can easily be modified later...

We should also provide a generic way to attach authentication
>> information to a thread that calls a service. I tought about using
>> apache shiro for this but I am not sure if it is universal enough.
>>
>
I don't understand why you need Shiro for this.
Isn't javax.security.auth.Subject.doAs() the standard way to do this?

Cheers,

David

Re: Some thoughts around adding security for Karaf Shell Commands

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

OSGi already provides the security module for that, and it's what David 
proposed (to "leverage" the services security).

An extension with Shiro (expecially now that we have Pax Shiro ;)) is a 
good idea.

Regards
JB

On 08/15/2013 10:16 PM, Christian Schneider wrote:
> I like the idea of adding permissions to the commands. I wonder though
> if this is perhaps a more general problem that not only affects commands.
>
> So how about adding a generic permission check for services? For example
> I would like to use the @RolesAllowed annotation to couple roles or
> permissions with service methods.
> A service registry hook could then check that the caller has the
> permission before allowing the call. Of course there could be other
> additional way of adding this information like the service properties
> you mentioned.
>
> We should also provide a generic way to attach authentication
> information to a thread that calls a service. I tought about using
> apache shiro for this but I am not sure if it is universal enough.
>
> What do you think?
>
> Christian
>
>
> Am 15.08.2013 16:26, schrieb davidb@apache.org:
>> Hi all,
>>
>> In the context of KARAF-2442 I started looking at securing the
>> commands in
>> the shell. I wanted to do something similar to what I did for the JMX
>> access (KARAF-2435) in that this should be configurable by a Karaf
>> administrator. I also really wanted a generic solution that would work
>> with
>> all commands, so that there would not be a big burden on the command
>> developer. I know that there was discussion about this in the context of
>> Karaf before, my approach here is a bit different...
>>
>> Here's what I came up with…
>> Karaf Commands are implemented OSGi services and one of the lesser known
>> features of the OSGi service registry is the fact that you can control
>> service registrations through service registry hooks. This effectively
>> allows you to change registrations, control who sees what
>> registrations and
>> also proxy service objects with some interceptor [1].
>> I thought that this might be a nice tool to use to add security to the
>> Karaf Commands from the outside, so I started an experimental
>> implementation with this:
>> * The roles that a specific Karaf Command needs in order to be executable
>> are defined in a ConfigAdmin config file in the etc/ directory. So
>> this can
>> easily be modified by an administrator. E.g I have a file that
>> controls who
>> can use the feature command, some example content:
>>    list = manager, viewer
>>    install = manager
>>    uninstall = admin
>> * I added a mechanism that effectively changes command service
>> registrations to add the required roles for the specific command -
>> based on
>> the ConfigAdmin data specified, e.g. the Service Registration for a
>> features:list command is turned into the following:
>>    osgi.command.scope=feature
>>    osgi.command.function=list
>>    org.apache.karaf.command.roles=[manager,viewer]
>> * The CommandProcessorImpl class in Karaf keeps track of what commands
>> are
>> there. Previously this was a global instance, but now we need one
>> instance
>> per shell console that selects the right commands for the user of that
>> console. It does this by reading off the current RolePrincipal objects
>> (that were put there by the JAAS login) and only selecting those commands
>> that have these roles by simply adding these as additional conditions to
>> the OSGi Service Registry selection filter.
>> * From there on everything works as normal. Tab completion etc, 'just
>> works'.
>>
>> The commands themselves are not modified. The required roles are added
>> externally, which is really easy for the command developer.
>> It's also pretty easy to change the required roles for commands either
>> directly in the etc/...cfg files or via the ConfigAdmin API...
>>
>> There are still a few things that I need to look at in more detail
>> (including defaults), but I wanted to run this by everyone to see what
>> people think, so feedback is appreciated!
>> If you're interested, I implemented this on a branch here:
>> https://github.com/bosschaert/karaf/commit/3e16bb515350bfb58e1a4b5d98045ccc1bcb1630
>>
>>
>> David
>>
>> davidb@apache.org
>> david@redhat.com
>> david.bosschaert@gmail.com
>>
>> [1] Detail: you don't really change a service registration, but can
>> hide it
>> from bundles and replace it with an alternative, which gives this
>> effect… I
>> wrote a blog about this a while ago:
>> http://coderthoughts.blogspot.ie/2009/11/altering-osgi-service-lookups-with.html
>>
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Some thoughts around adding security for Karaf Shell Commands

[Christian Schneider <ch...@die-schneider.net>]

I like the idea of adding permissions to the commands. I wonder though 
if this is perhaps a more general problem that not only affects commands.

So how about adding a generic permission check for services? For example 
I would like to use the @RolesAllowed annotation to couple roles or 
permissions with service methods.
A service registry hook could then check that the caller has the 
permission before allowing the call. Of course there could be other 
additional way of adding this information like the service properties 
you mentioned.

We should also provide a generic way to attach authentication 
information to a thread that calls a service. I tought about using 
apache shiro for this but I am not sure if it is universal enough.

What do you think?

Christian


Am 15.08.2013 16:26, schrieb davidb@apache.org:
> Hi all,
>
> In the context of KARAF-2442 I started looking at securing the commands in
> the shell. I wanted to do something similar to what I did for the JMX
> access (KARAF-2435) in that this should be configurable by a Karaf
> administrator. I also really wanted a generic solution that would work with
> all commands, so that there would not be a big burden on the command
> developer. I know that there was discussion about this in the context of
> Karaf before, my approach here is a bit different...
>
> Here's what I came up with…
> Karaf Commands are implemented OSGi services and one of the lesser known
> features of the OSGi service registry is the fact that you can control
> service registrations through service registry hooks. This effectively
> allows you to change registrations, control who sees what registrations and
> also proxy service objects with some interceptor [1].
> I thought that this might be a nice tool to use to add security to the
> Karaf Commands from the outside, so I started an experimental
> implementation with this:
> * The roles that a specific Karaf Command needs in order to be executable
> are defined in a ConfigAdmin config file in the etc/ directory. So this can
> easily be modified by an administrator. E.g I have a file that controls who
> can use the feature command, some example content:
>    list = manager, viewer
>    install = manager
>    uninstall = admin
> * I added a mechanism that effectively changes command service
> registrations to add the required roles for the specific command - based on
> the ConfigAdmin data specified, e.g. the Service Registration for a
> features:list command is turned into the following:
>    osgi.command.scope=feature
>    osgi.command.function=list
>    org.apache.karaf.command.roles=[manager,viewer]
> * The CommandProcessorImpl class in Karaf keeps track of what commands are
> there. Previously this was a global instance, but now we need one instance
> per shell console that selects the right commands for the user of that
> console. It does this by reading off the current RolePrincipal objects
> (that were put there by the JAAS login) and only selecting those commands
> that have these roles by simply adding these as additional conditions to
> the OSGi Service Registry selection filter.
> * From there on everything works as normal. Tab completion etc, 'just
> works'.
>
> The commands themselves are not modified. The required roles are added
> externally, which is really easy for the command developer.
> It's also pretty easy to change the required roles for commands either
> directly in the etc/...cfg files or via the ConfigAdmin API...
>
> There are still a few things that I need to look at in more detail
> (including defaults), but I wanted to run this by everyone to see what
> people think, so feedback is appreciated!
> If you're interested, I implemented this on a branch here:
> https://github.com/bosschaert/karaf/commit/3e16bb515350bfb58e1a4b5d98045ccc1bcb1630
>
> David
>
> davidb@apache.org
> david@redhat.com
> david.bosschaert@gmail.com
>
> [1] Detail: you don't really change a service registration, but can hide it
> from bundles and replace it with an alternative, which gives this effect… I
> wrote a blog about this a while ago:
> http://coderthoughts.blogspot.ie/2009/11/altering-osgi-service-lookups-with.html
>


-- 
  
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com