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 >> >> >> >
