karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: [Discussion] Security improvements
Date Mon, 30 Jan 2012 18:59:23 GMT
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