I've just committed the changes to 2.3.x branch. I'll try to backport it to trunk asap.
On Fri, Nov 2, 2012 at 8:28 AM, Guillaume Nodet <[email protected]> wrote: > That's kind of the reason why I did not decide to put that method in the > interface, because retrieval of the subject will certainly depend where you > come from. > If we add such providers, the camel one would have to use a thread local > one anyway to be able to access the exchange, so I'm not really convinced > it really helps. It's not more difficult to store the exchange in a thread > local and use a provider than just extracting the subject from the exchange > and pass it to the authorization service. > Also, if we have mutliple providers, I fear we won't be in control: we'd > have to use all the existing providers to find the subjects and combine > them when there are multiple ones. The consequence is that if you don't > want inferences from karaf and camel, you have to use different set of > roles. I guess that's not really a problem per se, but overall, i > currently fail to see the benefits. > > > On Thu, Nov 1, 2012 at 3:14 PM, Kurt Westerfeld <[email protected] > > wrote: > >> I am in favor of a private interface that has a default implementation, >> and one that shiro could provide. >> >> Could you add a "getCurrentSubject()" to your interface, or add another >> interface that has a default implementation for karaf commands? For >> example: >> >> public interface SubjectContext { >> Subject getCurrentSubject(); >> } >> >> Note: when utilizing Subject.doAs(), as karaf commands do, the "current" >> subject is held within a threadlocal within >> AccessControlContext/SubjectDomainCombiner, so the default implementation >> for SubjectContext.getCurrentSubject() can delegate to that. >> >> My feeling here is that there is a "SubjectContextProvider" SPI that >> needs to be 1:N within a Karaf implementation to obtain a subject. Within >> Camel, as an example, the current message exchange holds a subject as a >> specialized property. >> >> On Oct 31, 2012, at 7:24 PM, Guillaume Nodet <[email protected]> wrote: >> >> > Because that would be incompatible and require much more work. It's a >> > tradeoff I guess and I'm currently not yet convinced that it's really >> > needed, but as I said, I don't have any real objection at this point. >> > But what I'm working on is a real need, so we can revisit the underlying >> > implementation later, that's not really a problem as the interface would >> > not even have to change, while we can't really change the underlying >> > security implementation in a minor release such as 2.3 or 2.4 or just >> > before releasing 3.0 ... >> > >> > On Wed, Oct 31, 2012 at 9:58 PM, Andrei Pozolotin < >> > [email protected]> wrote: >> > >> >> 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]> <[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]> < >> [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]> < >> [email protected]>: >> >> >> >> andhttp:// >> 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]> <[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]> < >> [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]> < >> >> >> >> [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]> >> >> >> >> <[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]> < >> [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]> < >> >> >> >> [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 >> >> >> >> >> >> >> >> >> > >> > >> > -- >> > ------------------------ >> > 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 > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
