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 Mon, 19 Aug 2013 09:29:48 GMT
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


Mime
View raw message