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: [Discussion] Security improvements
Date Mon, 30 Jan 2012 16:15:41 GMT
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.


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

Open Source Architect
Talend Application Integration Division http://www.talend.com

View raw message