Return-Path: X-Original-To: apmail-karaf-dev-archive@minotaur.apache.org Delivered-To: apmail-karaf-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E7C37D996 for ; Mon, 12 Nov 2012 19:30:40 +0000 (UTC) Received: (qmail 42880 invoked by uid 500); 12 Nov 2012 19:30:40 -0000 Delivered-To: apmail-karaf-dev-archive@karaf.apache.org Received: (qmail 42853 invoked by uid 500); 12 Nov 2012 19:30:40 -0000 Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@karaf.apache.org Delivered-To: mailing list dev@karaf.apache.org Received: (qmail 42837 invoked by uid 99); 12 Nov 2012 19:30:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2012 19:30:40 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.215.176] (HELO mail-ea0-f176.google.com) (209.85.215.176) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2012 19:30:34 +0000 Received: by mail-ea0-f176.google.com with SMTP id n12so3217384eaa.21 for ; Mon, 12 Nov 2012 11:30:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=HSV0ZOj4G0OwGMgTWWAotJnltIlvS6Hf5qntgJS40Ko=; b=jdMquc6h2fOFZAnExCTfDV6+R5YeZZNJUEeT3JNGTDGPNkZrECvNT6sCE0H1zDiKRV PA/w7i/Ukw0wf5VnWap2bLJff7Iuy5vOFm8LCvhfX8MdlmxForzd1bX2/cCAiV+OEOuu M63cHm2YOvzlhNRSNJ8s+HRP/cymNFcTuoxQxXQ1d0Hd50r0DpQZh8hH9WscsdnPQtR4 5FJtgZhZ0wvIajrt6YMdRSF9vrqPwOCiECx5CCO14fOIig6sh84/CjqoJOqMUoXCD2sw Ek0qGz65xuSJNOWgNgfQwvZTusIOXU/j2INtrhCmdIftFhDNN+ymoQUqnXJQYlcRduDC LNpA== Received: by 10.14.203.3 with SMTP id e3mr66049211eeo.35.1352748612161; Mon, 12 Nov 2012 11:30:12 -0800 (PST) Received: from [192.168.1.131] ([176.241.243.167]) by mx.google.com with ESMTPS id 42sm17724926eee.0.2012.11.12.11.30.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 11:30:11 -0800 (PST) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Securing shell commands From: =?iso-8859-2?Q?=A3ukasz_Dywicki?= In-Reply-To: Date: Mon, 12 Nov 2012 20:30:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50903167.1020409@gmail.com> <50904429.9030708@gmail.com> <50905CDB.7020105@gmail.com> <50919101.5080105@gmail.com> <8A6A4A68-93E0-4465-B062-5ECA9A4E3AE6@gmail.com> To: dev@karaf.apache.org X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkT1UP+gYAFUIGh6I5biQe/EIZWfzwdILGEng8riykOCGnkT2J++uod2dzS0GYBZfiKGJBp X-Virus-Checked: Checked by ClamAV on apache.org As far I know you can use JAAS login modules without JVM level security = manager. It's only metter of creating the login context/module and so = on. However usage of SecurityManager gives us another big benefit - = possibility to integrate Karaf security with OSGi level permissions. What I see in another IAuthService is that nobody will support that. = Every single projects which could be possibly integrated with Karaf will = need to bridge all security things. I know you can implement that in = Camel or ActiveMQ, but from other hand did you get earlier = implementation of similar service for SMX3? Even if you will have this = then in 95% of cases you will bridge JAAS subject from Camel to = IAuthService in Karaf which will hide JAAS. You can not guarantee that = xml-security project will support karaf security layer. Thus usage of = WS-Security will always require 3rd party code to be produced. Every = time. If you would like to do things like integrating security layers from = different projects to run all together then I think the best place for = that is ServiceMix, not Karaf - as it was before. The XML structure you shown before looks like configuration of login = module for me. What we really need is pre-defined list of possible = actions to execute (in other words permissions), like = BundleStopPermission(bundle), BundleListPermission(framework/region). = Only one standard I know which supports that is JAAS. We are always running under OSGi. Here we already have a service to use = - it's called PermissionAdmin. As we are lightweight OSGi container we = definitely should rely on this, not some custom parts. Best regards, Lukasz Wiadomo=B6=E6 napisana przez Guillaume Nodet w dniu 12 lis 2012, o godz. = 14:36: > 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. >=20 > 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. >=20 >=20 > On Mon, Nov 12, 2012 at 1:30 PM, =A3ukasz Dywicki = wrote: >=20 >> I don't think that storing XML data inside flat configuration file is >> something I would like to see in karaf. >>=20 >> 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. >>=20 >> Best regards, >> Lukasz >>=20 >> Wiadomo=B6=E6 napisana przez Guillaume Nodet w dniu 6 lis 2012, o = godz. 11:14: >>=20 >>> I've just committed the changes to 2.3.x branch. >>> I'll try to backport it to trunk asap. >>>=20 >>>=20 >>> On Fri, Nov 2, 2012 at 8:28 AM, Guillaume Nodet >> wrote: >>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> On Thu, Nov 1, 2012 at 3:14 PM, Kurt Westerfeld < >> kurt.westerfeld@gmail.com >>>>> wrote: >>>>=20 >>>>> I am in favor of a private interface that has a default = implementation, >>>>> and one that shiro could provide. >>>>>=20 >>>>> Could you add a "getCurrentSubject()" to your interface, or add = another >>>>> interface that has a default implementation for karaf commands? = For >>>>> example: >>>>>=20 >>>>> public interface SubjectContext { >>>>> Subject getCurrentSubject(); >>>>> } >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> On Oct 31, 2012, at 7:24 PM, Guillaume Nodet = wrote: >>>>>=20 >>>>>> 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 ... >>>>>>=20 >>>>>> On Wed, Oct 31, 2012 at 9:58 PM, Andrei Pozolotin < >>>>>> andrei.pozolotin@gmail.com> wrote: >>>>>>=20 >>>>>>> in this case, why not drop jaas altogether, >>>>>>> and use shiro everywhere in karaf instead of jaas, >>>>>>> for everything, not just for "shell commands"? >>>>>>>=20 >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: Securing shell commands >>>>>>> From: Guillaume Nodet >>>>>>> To: dev@karaf.apache.org >>>>>>> Date: Wed 31 Oct 2012 02:47:58 AM CDT >>>>>>>=20 >>>>>>> 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); >>>>>>>=20 >>>>>>> I'm not sure there's a real use case for another third set of = methods >>>>> which >>>>>>> would use a List. >>>>>>>=20 >>>>>>> On Wed, Oct 31, 2012 at 12:03 AM, Andrei Pozolotin < >>>>> andrei.pozolotin@gmail.com> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> I mean why >>>>>>>=20 >>>>>>> void checkPermission(List principals, String = permission); >>>>>>>=20 >>>>>>> is not using >>>>>>>=20 >> http://docs.oracle.com/javase/6/docs/api/java/security/Principal.html >>>>>>>=20 >>>>>>> ? >>>>>>>=20 >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: Securing shell commands >>>>>>> From: Achim Nierbeck < >>>>> bcanhome@googlemail.com> >>>>>>> To: dev@karaf.apache.org >>>>>>> Date: Tue 30 Oct 2012 04:27:40 PM CDT >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I'm unsure about what you mean by this, but the UserPrincipal is = a >>>>>>> java.security.Principal implementation. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>=20 >> = https://github.com/apache/karaf/blob/trunk/jaas/boot/src/main/java/org/apa= che/karaf/jaas/boot/principal/UserPrincipal.java >>>>>>>=20 >>>>>>> Oh and by the way +1 for this concept :-D >>>>>>>=20 >>>>>>> regards, Achim >>>>>>>=20 >>>>>>> 2012/10/30 Andrei Pozolotin < >>>>> andrei.pozolotin@gmail.com>: >>>>>>>=20 >>>>>>> andhttp:// >>>>> docs.oracle.com/javase/6/docs/api/java/security/Principal.html >>>>>>>=20 >>>>>>> is wrong, because ...? >>>>>>>=20 >>>>>>>=20 >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: Securing shell commands >>>>>>> From: Guillaume Nodet >>>>>>> To: dev@karaf.apache.org >>>>>>> Date: Tue 30 Oct 2012 03:20:48 PM CDT >>>>>>>=20 >>>>>>> Permissions in JAAS can't be used with wildcards or permission = trees >>>>>>>=20 >>>>>>> for >>>>>>>=20 >>>>>>> example. >>>>>>> You'd have to define a permission for each command without any = way to >>>>>>> simplify the configuration. >>>>>>>=20 >>>>>>> On Tue, Oct 30, 2012 at 8:58 PM, Andrei Pozolotin < >>>>> andrei.pozolotin@gmail.com> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> what is the reason to stay away from >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>> = http://docs.oracle.com/javase/6/docs/api/java/security/Permission.html >>>>>>>=20 >>>>>>> in >>>>>>>=20 >>>>>>> void checkPermission(Subject subject, String permission); >>>>>>>=20 >>>>>>> vs >>>>>>>=20 >>>>>>> void checkPermission(Subject subject, Permission permission); >>>>>>>=20 >>>>>>> ? >>>>>>>=20 >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: Securing shell commands >>>>>>> From: Guillaume Nodet < >>>>> gnodet@gmail.com> >>>>>>> To: dev@karaf.apache.org, kurt@westerfeld.com >>>>>>> Date: Tue 30 Oct 2012 11:03:14 AM CDT >>>>>>>=20 >>>>>>> So what about a service defined like the following: >>>>>>>=20 >>>>>>> public interface AuthorizationService { >>>>>>>=20 >>>>>>> List getPrincipals(Subject subject); >>>>>>>=20 >>>>>>> void checkPermission(Subject subject, String permission); >>>>>>>=20 >>>>>>> boolean isPermitted(Subject subject, String permission); >>>>>>>=20 >>>>>>> void checkRole(Subject subject, String role); >>>>>>>=20 >>>>>>> boolean hasRole(Subject subject, String role); >>>>>>>=20 >>>>>>> void checkPermission(List principals, String = permission); >>>>>>>=20 >>>>>>> boolean isPermitted(List principals, String = permission); >>>>>>>=20 >>>>>>> void checkRole(List principals, String role); >>>>>>>=20 >>>>>>> boolean hasRole(List principals, String role); >>>>>>>=20 >>>>>>> } >>>>>>>=20 >>>>>>> All the methods taking a subject delegate to the corresponding = method >>>>>>>=20 >>>>>>> using >>>>>>>=20 >>>>>>> a List via a call to getPrincipals(Subject). >>>>>>> The translation is done by appending the Principal class name >>>>>>>=20 >>>>>>> (usually a >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> Thoughts ? >>>>>>>=20 >>>>>>> On Tue, Oct 30, 2012 at 4:32 PM, Guillaume Nodet = >> < >>>>> gnodet@gmail.com> < >>>>>>>=20 >>>>>>> gnodet@gmail.com> wrote: >>>>>>>=20 >>>>>>> Ok, that totally makes sense to me. >>>>>>> Let me enhance the interface to provide more non jaas tied = methods >>>>>>>=20 >>>>>>> and get >>>>>>>=20 >>>>>>> back to this list. >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tue, Oct 30, 2012 at 3:29 PM, Kurt Westerfeld < >>>>>>>=20 >>>>>>> kurt.westerfeld@gmail.com> wrote: >>>>>>>=20 >>>>>>> I was thinking of Shiro as a provider for the authorization = engine, >>>>>>>=20 >>>>>>> not as >>>>>>>=20 >>>>>>> the actual interfaces. >>>>>>>=20 >>>>>>> I actually think the container should provide a default >>>>>>>=20 >>>>>>> implementation for >>>>>>>=20 >>>>>>> security concerns. If you look at JEE, there are definitely >> standards >>>>>>> there, which haven't worked out perfectly, but at least are >>>>>>>=20 >>>>>>> constructs for >>>>>>>=20 >>>>>>> people to build on. In the OSGi world, I believe the container >>>>>>>=20 >>>>>>> should be >>>>>>>=20 >>>>>>> configurable to provide a default realm (it is in Karaf), and = there >>>>>>>=20 >>>>>>> should >>>>>>>=20 >>>>>>> be an easy mapping from the application to the container's = security >>>>>>>=20 >>>>>>> (this >>>>>>>=20 >>>>>>> isn't hard to do, but since it is left up to the developer, I = think >>>>>>>=20 >>>>>>> it's >>>>>>>=20 >>>>>>> not done that well). >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> other >>>>>>>=20 >>>>>>> concerns. If I want to do that myself, I can make a separate = choice >>>>>>>=20 >>>>>>> on >>>>>>>=20 >>>>>>> the >>>>>>> login realm to tie my application to it's own config. >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> there's a >>>>>>>=20 >>>>>>> lot of value-add in at least putting a stake in the ground as to = how >>>>>>>=20 >>>>>>> one >>>>>>>=20 >>>>>>> obtains a Subject. Each component library, as an example, could >>>>>>>=20 >>>>>>> provide >>>>>>>=20 >>>>>>> an >>>>>>> implementation of a provider of Subject material it its own way, = and >>>>>>>=20 >>>>>>> from >>>>>>>=20 >>>>>>> an application point-of-view, one would simply call >>>>>>>=20 >>>>>>> "getCurrentSubject()". >>>>>>>=20 >>>>>>> In my opinion, that's not always an easy thing to get right. >>>>>>>=20 >>>>>>> On Tue, Oct 30, 2012 at 10:22 AM, Guillaume Nodet = >> < >>>>> gnodet@gmail.com> >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Thx for the feedback, Kurt. >>>>>>>=20 >>>>>>> I've looked at Shiro when working on this feature. Actually, = the >>>>>>> interface, and even a class I use for the implementation come = from >>>>>>>=20 >>>>>>> shiro. >>>>>>>=20 >>>>>>> The reason why I discarded reusing shiro directly is mainly that = it >>>>>>>=20 >>>>>>> does >>>>>>>=20 >>>>>>> not provide the features we need. However, that's clearly not a >>>>>>>=20 >>>>>>> blocking >>>>>>>=20 >>>>>>> point and we could very well reimplement them all on top of = shiro, >>>>>>>=20 >>>>>>> mostly >>>>>>>=20 >>>>>>> the realms would not necessarily cover our use cases I think, or = at >>>>>>>=20 >>>>>>> least, >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> that >>>>>>>=20 >>>>>>> way, not sure if that's really a good idea though. >>>>>>>=20 >>>>>>> However, the exemple you have is clearly on the app level, and >> there's >>>>>>>=20 >>>>>>> imho >>>>>>>=20 >>>>>>> not a real need to have application security integrated with the >>>>>>>=20 >>>>>>> container >>>>>>>=20 >>>>>>> security. If you deploy shiro in a web app, you clearly not >>>>>>>=20 >>>>>>> integrate >>>>>>>=20 >>>>>>> with >>>>>>>=20 >>>>>>> the web container security, so I don't think this is a real = problem. >>>>>>>=20 >>>>>>> So >>>>>>>=20 >>>>>>> applications still clearly have the option of deploying shiro = and >>>>>>> configuring it for their needs. >>>>>>>=20 >>>>>>> I'm happy to discuss that further if people have other opinions. = The >>>>>>>=20 >>>>>>> above >>>>>>>=20 >>>>>>> just explains why i didn't choose shiro at first and I certainly >>>>>>>=20 >>>>>>> don't >>>>>>>=20 >>>>>>> want >>>>>>>=20 >>>>>>> to reject this option without discussion. >>>>>>>=20 >>>>>>> On Tue, Oct 30, 2012 at 2:49 PM, Kurt Westerfeld< >>>>>>>=20 >>>>>>> kurt.westerfeld@gmail.com> < >>>>> kurt.westerfeld@gmail.com>wrote: >>>>>>>=20 >>>>>>> I think the problem you find as you go down this route, is not = that >>>>>>>=20 >>>>>>> this >>>>>>>=20 >>>>>>> checkPermission/isPermitted won't work for this command = interface, >>>>>>>=20 >>>>>>> but >>>>>>>=20 >>>>>>> that >>>>>>>=20 >>>>>>> there is a more fundamental problem across Karaf-based apps and >>>>>>>=20 >>>>>>> enterprise >>>>>>>=20 >>>>>>> apps in general, in that a javax.security.auth.Subject may = actually >>>>>>>=20 >>>>>>> be a >>>>>>>=20 >>>>>>> difficult thing to uniformly provide. This is because of the >>>>>>>=20 >>>>>>> asynchronous >>>>>>>=20 >>>>>>> nature of Camel/ODE/whatever even within a short-run transaction = in >>>>>>>=20 >>>>>>> an >>>>>>>=20 >>>>>>> ESB, >>>>>>>=20 >>>>>>> and also commonly, the way in which long-running processes can >>>>>>> hibernate/unhibernate their context/state over time before a >>>>>>>=20 >>>>>>> particular >>>>>>>=20 >>>>>>> service might actually need the Subject information an = originating >>>>>>>=20 >>>>>>> caller >>>>>>>=20 >>>>>>> to a service actually had. >>>>>>>=20 >>>>>>> Simplest case: >>>>>>> - web service call call is authenticated, via basic auth, >>>>>>>=20 >>>>>>> WS-Security, >>>>>>>=20 >>>>>>> whatever >>>>>>> - web service calls camel >>>>>>> - camel route implements vm: queue, which blocks caller until >>>>>>>=20 >>>>>>> complete >>>>>>>=20 >>>>>>> - route actually needs Subject, but thread-local context = techniques >>>>>>> don't work here >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> stuff >>>>>>>=20 >>>>>>> yourself), but you can see a need here to have something like >>>>>>> "getSubject()" as a globally-applicable construct in Karaf/ESB >>>>>>> implementations. >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> providing >>>>>>>=20 >>>>>>> the >>>>>>>=20 >>>>>>> subject for any caller. In some cases, a thread-local could = suffice, >>>>>>>=20 >>>>>>> and >>>>>>>=20 >>>>>>> in other cases another strategy had to be used (such as stashing = the >>>>>>>=20 >>>>>>> data >>>>>>>=20 >>>>>>> inside a CXF message header, etc). >>>>>>>=20 >>>>>>> As to your interface, I would also add methods such as >>>>>>>=20 >>>>>>> "hasRole(String)" >>>>>>>=20 >>>>>>> because it could be a more convenient way to deal with this. >>>>>>>=20 >>>>>>> Have you looked at Apache Shiro? I think there's a lot to be = learned >>>>>>>=20 >>>>>>> from >>>>>>>=20 >>>>>>> there, and I've started to use Shiro in some of my projects. >>>>>>>=20 >>>>>>> On Oct 30, 2012, at 7:20 AM, Guillaume Nodet = < >>>>> gnodet@gmail.com> < >>>>>>>=20 >>>>>>> gnodet@gmail.com> >>>>>>>=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>> I've worked last week on a solution for KARAF-979, i.e. = providing a >>>>>>>=20 >>>>>>> way >>>>>>>=20 >>>>>>> to >>>>>>>=20 >>>>>>> secure shell commands. >>>>>>> What I came up with is the following. >>>>>>>=20 >>>>>>> A new simple authentication service, exposed as an OSGi service = with >>>>>>>=20 >>>>>>> the >>>>>>>=20 >>>>>>> following interface >>>>>>>=20 >>>>>>> public interface AuthorizationService { >>>>>>>=20 >>>>>>> void checkPermission(Subject subject, String permission); >>>>>>>=20 >>>>>>> boolean isPermitted(Subject subject, String permission); >>>>>>>=20 >>>>>>> } >>>>>>>=20 >>>>>>>=20 >>>>>>> This service would be used transparently by karaf commands by >>>>>>>=20 >>>>>>> modifying >>>>>>>=20 >>>>>>> the >>>>>>>=20 >>>>>>> BlueprintCommand class and calling checkPermission with the = current >>>>>>>=20 >>>>>>> Subject >>>>>>>=20 >>>>>>> and a permission which is >>>>>>> "command:" + [scope] + ":" + [command] >>>>>>>=20 >>>>>>> Permissions can be set through ConfigAdmin using a single = property >>>>>>>=20 >>>>>>> which >>>>>>>=20 >>>>>>> contains an xml which looks like: >>>>>>> >>>>>>> >>>>>>=20 >>>>>>> /> >>>>>>>=20 >>>>>>> [ more entries ] >>>>>>> >>>>>>>=20 >>>>>>> The matching is done by checking the permission given in the = call to >>>>>>>=20 >>>>>>> the >>>>>>>=20 >>>>>>> AuthorizationService with the entries in the configuration. >>>>>>>=20 >>>>>>> Matching >>>>>>>=20 >>>>>>> entries are used to compute the list of authorized roles and = those >>>>>>>=20 >>>>>>> roles >>>>>>>=20 >>>>>>> are checked against the roles of the authenticated Subject. >>>>>>> This mechanism is the same we had in ServiceMix 3.x. >>>>>>>=20 >>>>>>> This allows to define permissions for a subshell or a single >>>>>>>=20 >>>>>>> command. >>>>>>>=20 >>>>>>> It >>>>>>>=20 >>>>>>> does not provide a very easy way to split read operations from = write >>>>>>> operations and this would have to be done in an example >>>>>>>=20 >>>>>>> configuration >>>>>>>=20 >>>>>>> maybe >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> benefit >>>>>>>=20 >>>>>>> from that. >>>>>>>=20 >>>>>>> Thoughts welcomed, as usual. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> ------------------------ >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> FuseSource, Integration everywherehttp://fusesource.com >>>>>>>=20 >>>>>>> -- >>>>>>> ------------------------ >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> FuseSource, Integration everywherehttp://fusesource.com >>>>>>>=20 >>>>>>> -- >>>>>>> ------------------------ >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> FuseSource, Integration everywherehttp://fusesource.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> ------------------------ >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> FuseSource, Integration everywhere >>>>>> http://fusesource.com >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> FuseSource, Integration everywhere >>>> http://fusesource.com >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> ------------------------ >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> FuseSource, Integration everywhere >>> http://fusesource.com >>=20 >>=20 >=20 >=20 > --=20 > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com