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 <andrei.pozolo...@gmail.com>: > 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 <gno...@gmail.com> > To: dev@karaf.apache.org > 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 < >> andrei.pozolo...@gmail.com> 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 <gno...@gmail.com> <gno...@gmail.com> >>> To: dev@karaf.apache.org, k...@westerfeld.com >>> 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 <gno...@gmail.com> >>> <gno...@gmail.com> 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 >>> <kurt.westerf...@gmail.com> 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 <gno...@gmail.com> >>> <gno...@gmail.com> >>> 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<kurt.westerf...@gmail.com> >>> <kurt.westerf...@gmail.com>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 <gno...@gmail.com> >>> <gno...@gmail.com> >>> >>> 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 >>> >>> >>> >> > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
