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 19:09:24 GMT
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