Could you explain how you would do that with pure JAAS without requiring a security manager ? Security manager is not always the best option. And I haven't seen many projects forcing its use for simple authorization.
I agree that xml is not perfect, especially in that case, the main reason, but a flat property file with ordering is not easy to write either. Another option would be to use a url which would point to the xml, or text base file. But properties are map based with no ordering guarantee. On Mon, Nov 12, 2012 at 1:30 PM, Łukasz Dywicki <[email protected]> wrote: > I don't think that storing XML data inside flat configuration file is > something I would like to see in karaf. > > Nobody will be able to edit that to be honest. Implementation of > wildcards/RBAC can be done easily with JAAS LoginModule. So from my point > of view it's -1. > I see no need for introducing another custom interface. > > Best regards, > Lukasz > > Wiadomość napisana przez Guillaume Nodet w dniu 6 lis 2012, o godz. 11:14: > > > I've just committed the changes to 2.3.x branch. > > I'll try to backport it to trunk asap. > > > > > > On Fri, Nov 2, 2012 at 8:28 AM, Guillaume Nodet <[email protected]> > wrote: > > > >> That's kind of the reason why I did not decide to put that method in the > >> interface, because retrieval of the subject will certainly depend where > you > >> come from. > >> If we add such providers, the camel one would have to use a thread local > >> one anyway to be able to access the exchange, so I'm not really > convinced > >> it really helps. It's not more difficult to store the exchange in a > thread > >> local and use a provider than just extracting the subject from the > exchange > >> and pass it to the authorization service. > >> Also, if we have mutliple providers, I fear we won't be in control: we'd > >> have to use all the existing providers to find the subjects and combine > >> them when there are multiple ones. The consequence is that if you don't > >> want inferences from karaf and camel, you have to use different set of > >> roles. I guess that's not really a problem per se, but overall, i > >> currently fail to see the benefits. > >> > >> > >> On Thu, Nov 1, 2012 at 3:14 PM, Kurt Westerfeld < > [email protected] > >>> wrote: > >> > >>> I am in favor of a private interface that has a default implementation, > >>> and one that shiro could provide. > >>> > >>> Could you add a "getCurrentSubject()" to your interface, or add another > >>> interface that has a default implementation for karaf commands? For > >>> example: > >>> > >>> public interface SubjectContext { > >>> Subject getCurrentSubject(); > >>> } > >>> > >>> Note: when utilizing Subject.doAs(), as karaf commands do, the > "current" > >>> subject is held within a threadlocal within > >>> AccessControlContext/SubjectDomainCombiner, so the default > implementation > >>> for SubjectContext.getCurrentSubject() can delegate to that. > >>> > >>> My feeling here is that there is a "SubjectContextProvider" SPI that > >>> needs to be 1:N within a Karaf implementation to obtain a subject. > Within > >>> Camel, as an example, the current message exchange holds a subject as a > >>> specialized property. > >>> > >>> On Oct 31, 2012, at 7:24 PM, Guillaume Nodet <[email protected]> wrote: > >>> > >>>> 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 > >>> > >>> > >> > >> > >> -- > >> ------------------------ > >> 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
