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
