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