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 Tue, 31 Jan 2012 13:28:52 GMT
You're probably right that Shiro doesn't support all low-level permissions
the way JAAS does. Which I guess means that JAAS cannot go away. On the
other hand JAAS is totally unuitable for complex authorisation based on
permission hierarchies and roles.

In order to cover both ends I think that JAAS + something else (perhaps
Shiro) is needed. Don't know how they would inter-operate though. Also,
perhaps Karaf does not want another dependency...

It would be nice if JAAS and Shiro could inter-operate somehow. Then you
could have very coarse grained security in Karaf core and optionally allow
the developers to use Shiro for fine grained security (with an optional
dependency).

/Bengt

2012/1/31 Łukasz Dywicki <luke@code-house.org>

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message