karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [Discussion] Security improvements
Date Tue, 14 Feb 2012 17:30:13 GMT
Note that UI already does authentication, so it should just be about
checking that the authenticated user has the correct roles.
The same checks are done in ssh, jmx, and felix web console and the
user should be associated to the current thread in JAAS.

For commands, maybe we need a simple syntax to associate commands to
roles using wildcards.  James suggested something like

scope:command = list of roles who can use it

For example:

shell:* = *
bundle:* = operations
bundle:list = *
dev:(list-agents list-profiles) = developer
config:* = operations developer

We'd also need a way to do the same for jmx actions and the web
console, and also a way to forbid introspection in gogo.
On the last part, one first step would be to check access to session
variables such as $.context which gives an entry point into the osgi
api.

2012/1/30 Christian Schneider <chris@die-schneider.net>:
> I think a typical system for authorization would have resource level rights
> like "bundle:install" and high level roles that each have a set of those
> rights.
> This works of course but is a lot of configuration work. So we should be
> sure we really need that before we implement it.
>
> Another thing is that I think it only makes very limited sense to have
> authorization only on the UI level like Karaf commands or webconsole. The
> core are the
> services and there the authorization is most important. In the UI I would
> use the roles and rights mostly to make things visible or not. So it would
> be a convenience feature
> to see only the commands you may call but even if you can see all the
> services behind the commands should block access to anything you should not
> be able to do.
>
> So to make this work we have to do authentication on the UI level and then
> forward the authorized principle to the service call where it should be
> checked. Ideally the forwarding and checking should be mostly transparent so
> we do not have to litter the whole "business" code with security code.
>
> Any ideas how this can be done in OSGi? I have read about using  java
> security manager with OSGi but I am not sure if this is the right way.
>
> As Guillaume wrote we should have real use cases. For example if the only
> one who has access to the Karaf shell or web console then it makes no sense
> to have fine grained security.
>
> Christian
>
> Am 30.01.2012 16:28, schrieb Guillaume Nodet:
>
>> Then, we're talking more about authorization than roles, which makes
>> sense to me.
>> But we should not mix both.  So what you're wiring is more command
>> level authorization, but we should not use roles to explicit those.
>>
>> Defining a role per command is just not scalable and new commands
>> won't be able to leverage them.  I think we need a mechanism that can
>> support coarse grained role definition and I don't think this goes in
>> that way.
>>
>> I may have missed something in your explanation, but I don't really
>> like the idea to have one role per command.
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Mime
View raw message