Thx for the feedback, Kurt. I've looked at Shiro when working on this feature. Actually, the interface, and even a class I use for the implementation come from shiro. The reason why I discarded reusing shiro directly is mainly that it does not provide the features we need. However, that's clearly not a blocking point and we could very well reimplement them all on top of shiro, mostly the realms would not necessarily cover our use cases I think, or at least, we'd have to break compatibility completely. Or maybe another way to integrate would be to implement a jaas realm based on shiro and bridge that way, not sure if that's really a good idea though.
However, the exemple you have is clearly on the app level, and there's imho not a real need to have application security integrated with the container security. If you deploy shiro in a web app, you clearly not integrate with the web container security, so I don't think this is a real problem. So applications still clearly have the option of deploying shiro and configuring it for their needs. I'm happy to discuss that further if people have other opinions. The above just explains why i didn't choose shiro at first and I certainly don't want to reject this option without discussion. On Tue, Oct 30, 2012 at 2:49 PM, Kurt Westerfeld <[email protected]>wrote: > I think the problem you find as you go down this route, is not that this > checkPermission/isPermitted won't work for this command interface, but that > there is a more fundamental problem across Karaf-based apps and enterprise > apps in general, in that a javax.security.auth.Subject may actually be a > difficult thing to uniformly provide. This is because of the asynchronous > nature of Camel/ODE/whatever even within a short-run transaction in an ESB, > and also commonly, the way in which long-running processes can > hibernate/unhibernate their context/state over time before a particular > service might actually need the Subject information an originating caller > to a service actually had. > > Simplest case: > - web service call call is authenticated, via basic auth, WS-Security, > whatever > - web service calls camel > - camel route implements vm: queue, which blocks caller until complete > - route actually needs Subject, but thread-local context techniques > don't work here > > Now, perhaps Camel has resolved this (it hadn't a while back), and > something like Apache ODE definitely hasn't (you have to manage this stuff > yourself), but you can see a need here to have something like > "getSubject()" as a globally-applicable construct in Karaf/ESB > implementations. > > In one project that combined Java services, Camel services, and ODE > services, I had to create a SPI mechanism with OSGi to allow different > "providers" of javax.security.auth.Subject to have a crack at providing the > subject for any caller. In some cases, a thread-local could suffice, and > in other cases another strategy had to be used (such as stashing the data > inside a CXF message header, etc). > > As to your interface, I would also add methods such as "hasRole(String)" > because it could be a more convenient way to deal with this. > > Have you looked at Apache Shiro? I think there's a lot to be learned from > there, and I've started to use Shiro in some of my projects. > > On Oct 30, 2012, at 7:20 AM, Guillaume Nodet <[email protected]> wrote: > > > I've worked last week on a solution for KARAF-979, i.e. providing a way > to > > secure shell commands. > > What I came up with is the following. > > > > A new simple authentication service, exposed as an OSGi service with the > > following interface > > > > public interface AuthorizationService { > > > > void checkPermission(Subject subject, String permission); > > > > boolean isPermitted(Subject subject, String permission); > > > > } > > > > > > This service would be used transparently by karaf commands by modifying > the > > BlueprintCommand class and calling checkPermission with the current > Subject > > and a permission which is > > "command:" + [scope] + ":" + [command] > > > > Permissions can be set through ConfigAdmin using a single property which > > contains an xml which looks like: > > <entries> > > <entry permission="[xxx]" roles="[xxx]" type="add|set|modify" /> > > [ more entries ] > > </entries> > > > > The matching is done by checking the permission given in the call to the > > AuthorizationService with the entries in the configuration. Matching > > entries are used to compute the list of authorized roles and those roles > > are checked against the roles of the authenticated Subject. > > This mechanism is the same we had in ServiceMix 3.x. > > > > This allows to define permissions for a subshell or a single command. It > > does not provide a very easy way to split read operations from write > > operations and this would have to be done in an example configuration > maybe > > to ease the user task. > > That said, the mechanism is easily extensible and we can later add > > permissions for JMX access or any other part of Karaf that would benefit > > from that. > > > > Thoughts welcomed, as usual. > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > FuseSource, Integration everywhere > > http://fusesource.com > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
