karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: [Discussion] Security improvements
Date Tue, 31 Jan 2012 13:06:41 GMT
Hi,
The Shiro proposal looks sexy, but we can not leave JAAS. As the security mechanism, JAAS
is an standard built in in many places where we need it. For example we can control reflection
access by using a corresponding permission.

From one hand we need typical authorization for web application up to singular resource level,
from other we need a low level security layer for gogo. That's can not be controled only by
Shiro nor SpringSecurity.

I believe that Shiro is correct solution for part of our problems but I also a bit afraid
about adding next dependency to Karaf core.

Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org

Wiadomość napisana przez Bengt Rodehav w dniu 30 sty 2012, o godz. 20:09:

> You are of course right Andreas. I just wanted to mention that moving to
> Shiro instead of sticking with JAAS might make the implementation a lot
> easier and more flexible.
> 
> /Bengt
> 
> 2012/1/30 Andreas Pieber <anpieber@gmail.com>
> 
>> Shiro will also work with apache wicket quite fine. But I think we should
>> rather fixate first what we want to do and then decide how to do this.
>> 
>> Kind regards,
>> Andreas
>> On Jan 30, 2012 6:45 PM, "Bengt Rodehav" <bengt@rodehav.com> wrote:
>> 
>>> 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:
>>> 
>>> http://shiro.apache.org/authorization.html
>>> 
>>> And to learn more about the flexibility with Shiro's permissions look at
>>> this:
>>> 
>>> http://shiro.apache.org/permissions.html
>>> 
>>> I think it would be a perfect fit.
>>> 
>>> /Bengt
>>> 
>>> 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
>>>> 
>>>> 
>>> 
>> 


Mime
View raw message