karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Some thoughts around adding security for Karaf Shell Commands
Date Thu, 15 Aug 2013 20:23:49 GMT
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.


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é
Talend - http://www.talend.com

View raw message