yes on both. On Tue, Oct 30, 2012 at 5:05 PM, Claus Ibsen <[email protected]> wrote:
> 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 > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
