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 <anpie...@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" <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 > > > > > > > > >
