Hi What is the difference between the void and the boolean methods? Would the void throw any exceptions if check fails, or how is that to be understood?
And I assume javadoc is added to the interface + methods. On Tue, Oct 30, 2012 at 5:03 PM, Guillaume Nodet <[email protected]> wrote: > 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 >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
