karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Some thoughts around adding security for Karaf Shell Commands
Date Mon, 19 Aug 2013 08:55:09 GMT
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?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message