karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: [Discussion] Security improvements
Date Mon, 30 Jan 2012 17:45:14 GMT
I use Apache Shiro for both authentication and authorisation. JAAS is far
from ideal when it comes to complex authorisation schemes. The command tree
that you are talking about could be mapped using permissions in Shiro. You
would then create roles as needed - both fine grained and coarse grained
(which most would do).

I'm not an expert but have a look at this:


And to learn more about the flexibility with Shiro's permissions look at


I think it would be a perfect fit.


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

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