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