Because that would be incompatible and require much more work. It's a tradeoff I guess and I'm currently not yet convinced that it's really needed, but as I said, I don't have any real objection at this point. But what I'm working on is a real need, so we can revisit the underlying implementation later, that's not really a problem as the interface would not even have to change, while we can't really change the underlying security implementation in a minor release such as 2.3 or 2.4 or just before releasing 3.0 ...
On Wed, Oct 31, 2012 at 9:58 PM, Andrei Pozolotin < [email protected]> wrote: > in this case, why not drop jaas altogether, > and use shiro everywhere in karaf instead of jaas, > for everything, not just for "shell commands"? > > -------- Original Message -------- > Subject: Re: Securing shell commands > From: Guillaume Nodet <[email protected]> <[email protected]> > To: [email protected] > Date: Wed 31 Oct 2012 02:47:58 AM CDT > > Because Kurt noted that obtaining an authenticated JAAS subject can be > difficult in some contexts and opening the interface makes it more reusable. > If you can access the JAAS subject, one would use the > void checkPermission(Subject subject, String permission); > > I'm not sure there's a real use case for another third set of methods which > would use a List<Principal>. > > On Wed, Oct 31, 2012 at 12:03 AM, Andrei Pozolotin > <[email protected]> wrote: > > > 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]> <[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]> > <[email protected]>: > > andhttp://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]> <[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]> > <[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]> < > > [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]> > > <[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]> > <[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]> < > > [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 > > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
