in this case, why not drop jaas altogether, and use shiro everywhere in karaf instead of jaas, for everything, not just for "shell commands"?
-------- Original Message -------- Subject: Re: Securing shell commands From: Guillaume Nodet <[email protected]> To: [email protected] Date: Wed 31 Oct 2012 02:47:58 AM CDT > Because Kurt noted that obtaining an authenticated JAAS subject can be > difficult in some contexts and opening the interface makes it more reusable. > If you can access the JAAS subject, one would use the > void checkPermission(Subject subject, String permission); > > I'm not sure there's a real use case for another third set of methods which > would use a List<Principal>. > > On Wed, Oct 31, 2012 at 12:03 AM, Andrei Pozolotin < > [email protected]> wrote: > >> I mean why >> >> void checkPermission(List<String> principals, String permission); >> >> is not using >> >> http://docs.oracle.com/javase/6/docs/api/java/security/Principal.html >> >> ? >> >> -------- Original Message -------- >> Subject: Re: Securing shell commands >> From: Achim Nierbeck <[email protected]> >> To: [email protected] >> Date: Tue 30 Oct 2012 04:27:40 PM CDT >>> Hi, >>> >>> I'm unsure about what you mean by this, but the UserPrincipal is a >>> java.security.Principal implementation. >>> >>> >> https://github.com/apache/karaf/blob/trunk/jaas/boot/src/main/java/org/apache/karaf/jaas/boot/principal/UserPrincipal.java >>> >>> >>> Oh and by the way +1 for this concept :-D >>> >>> regards, Achim >>> >>> 2012/10/30 Andrei Pozolotin <[email protected]>: >>>> and >>>> http://docs.oracle.com/javase/6/docs/api/java/security/Principal.html >>>> >>>> is wrong, because ...? >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: Securing shell commands >>>> From: Guillaume Nodet <[email protected]> >>>> To: [email protected] >>>> Date: Tue 30 Oct 2012 03:20:48 PM CDT >>>>> Permissions in JAAS can't be used with wildcards or permission trees >> for >>>>> example. >>>>> You'd have to define a permission for each command without any way to >>>>> simplify the configuration. >>>>> >>>>> On Tue, Oct 30, 2012 at 8:58 PM, Andrei Pozolotin < >>>>> [email protected]> wrote: >>>>> >>>>>> what is the reason to stay away from >>>>>> >>>>>> >> http://docs.oracle.com/javase/6/docs/api/java/security/Permission.html >>>>>> in >>>>>> >>>>>> void checkPermission(Subject subject, String permission); >>>>>> >>>>>> vs >>>>>> >>>>>> void checkPermission(Subject subject, Permission permission); >>>>>> >>>>>> ? >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: Securing shell commands >>>>>> From: Guillaume Nodet <[email protected]> <[email protected]> >>>>>> To: [email protected], [email protected] >>>>>> Date: Tue 30 Oct 2012 11:03:14 AM CDT >>>>>> >>>>>> So what about a service defined like the following: >>>>>> >>>>>> public interface AuthorizationService { >>>>>> >>>>>> List<String> getPrincipals(Subject subject); >>>>>> >>>>>> void checkPermission(Subject subject, String permission); >>>>>> >>>>>> boolean isPermitted(Subject subject, String permission); >>>>>> >>>>>> void checkRole(Subject subject, String role); >>>>>> >>>>>> boolean hasRole(Subject subject, String role); >>>>>> >>>>>> void checkPermission(List<String> principals, String permission); >>>>>> >>>>>> boolean isPermitted(List<String> principals, String permission); >>>>>> >>>>>> void checkRole(List<String> principals, String role); >>>>>> >>>>>> boolean hasRole(List<String> principals, String role); >>>>>> >>>>>> } >>>>>> >>>>>> All the methods taking a subject delegate to the corresponding method >> using >>>>>> a List<String> via a call to getPrincipals(Subject). >>>>>> The translation is done by appending the Principal class name >> (usually a >>>>>> org.apache.karaf.jaas.boot.principal.RolePrincipal) with the principal >>>>>> name, separated by a column, so something like: >>>>>> org.apache.karaf.jaas.boot.principal.RolePrincipal:karaf >>>>>> >>>>>> Thoughts ? >>>>>> >>>>>> On Tue, Oct 30, 2012 at 4:32 PM, Guillaume Nodet <[email protected]> < >> [email protected]> wrote: >>>>>> >>>>>> Ok, that totally makes sense to me. >>>>>> Let me enhance the interface to provide more non jaas tied methods >> and get >>>>>> back to this list. >>>>>> >>>>>> >>>>>> On Tue, Oct 30, 2012 at 3:29 PM, Kurt Westerfeld < >> [email protected]> wrote: >>>>>> >>>>>> I was thinking of Shiro as a provider for the authorization engine, >> not as >>>>>> the actual interfaces. >>>>>> >>>>>> I actually think the container should provide a default >> implementation for >>>>>> security concerns. If you look at JEE, there are definitely standards >>>>>> there, which haven't worked out perfectly, but at least are >> constructs for >>>>>> people to build on. In the OSGi world, I believe the container >> should be >>>>>> configurable to provide a default realm (it is in Karaf), and there >> should >>>>>> be an easy mapping from the application to the container's security >> (this >>>>>> isn't hard to do, but since it is left up to the developer, I think >> it's >>>>>> not done that well). >>>>>> >>>>>> For example, if I decide to tie my Karaf implementation to LDAP, I can >>>>>> provide config to do that. Now, I'd like it if by doing that, my >>>>>> application is wired to that LDAP provider and I just move along to >> other >>>>>> concerns. If I want to do that myself, I can make a separate choice >> on >>>>>> the >>>>>> login realm to tie my application to it's own config. >>>>>> >>>>>> The main point I was making, though, is that your interface requires a >>>>>> Subject. Getting one of those is not always an easy thing, and >> there's a >>>>>> lot of value-add in at least putting a stake in the ground as to how >> one >>>>>> obtains a Subject. Each component library, as an example, could >> provide >>>>>> an >>>>>> implementation of a provider of Subject material it its own way, and >> from >>>>>> an application point-of-view, one would simply call >> "getCurrentSubject()". >>>>>> In my opinion, that's not always an easy thing to get right. >>>>>> >>>>>> On Tue, Oct 30, 2012 at 10:22 AM, Guillaume Nodet <[email protected]> >> <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> 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]> <[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]> < >> [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 everywherehttp://fusesource.com >>>>>> >>>>>> -- >>>>>> ------------------------ >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> FuseSource, Integration everywherehttp://fusesource.com >>>>>> >>>>>> -- >>>>>> ------------------------ >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> FuseSource, Integration everywherehttp://fusesource.com >>>>>> >>>>>> >>>>>> >>> >> >
