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 [email protected]:
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
[email protected]
[email protected]
[email protected]
[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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
