karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Some thoughts around adding security for Karaf Shell Commands
Date Thu, 15 Aug 2013 20:16:40 GMT
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?


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

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

View raw message