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" <be...@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 <ch...@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 > > > > >
