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 EC1CBD094 for ; Mon, 12 Nov 2012 21:39:32 +0000 (UTC) Received: (qmail 31441 invoked by uid 500); 12 Nov 2012 21:39:32 -0000 Delivered-To: apmail-karaf-dev-archive@karaf.apache.org Received: (qmail 31408 invoked by uid 500); 12 Nov 2012 21:39:32 -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 31399 invoked by uid 99); 12 Nov 2012 21:39:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2012 21:39:32 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.83.48] (HELO mail-ee0-f48.google.com) (74.125.83.48) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2012 21:39:27 +0000 Received: by mail-ee0-f48.google.com with SMTP id b57so751066eek.21 for ; Mon, 12 Nov 2012 13:39:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=L60ooj+mzmfPAktVI9qmKrduYHmtqfIBmy3mufWPj9k=; b=CV2JhB80II7HEdQ0qBRsSCsLnvPkdjM62wgwo52J8wMdbQQjeai+3tc1a/uAtwLXGg mEG/Ko8Lm/nN0ymksUHseEHyb/D0SdKNJaziX55YPi5mr5c7jTYBzhygLnXuVdgqrb0y +Ln9LK/UVIQtUgn71nX+4zBbenIq6wn+T5MmANOv2SaRj2r7RYybuD+lbP2Lr1fTbxjW tarGWrhc/1kxN0taieiAbRFVfYEZXIh3UAmgYt0rw4jVQtHwMG8z23e3APZmEPZNrjWO 29xj+TbrI0ENzcKpWxL1sFr9tbyCYM2WQkZFC7NIVuQLcaPTLm+t8EiptFr/yA84/L2H wfSg== Received: by 10.14.215.69 with SMTP id d45mr67023026eep.16.1352756345182; Mon, 12 Nov 2012 13:39:05 -0800 (PST) Received: from [192.168.1.131] ([176.241.243.167]) by mx.google.com with ESMTPS id g47sm18371202eeo.6.2012.11.12.13.39.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 13:39:04 -0800 (PST) From: =?iso-8859-2?Q?=A3ukasz_Dywicki?= Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0714629D-1875-4D9C-8555-6BDCED345AC8" Subject: Re: Securing shell commands Date: Mon, 12 Nov 2012 22:39:00 +0100 In-Reply-To: To: dev@karaf.apache.org References: <50903167.1020409@gmail.com> <50904429.9030708@gmail.com> <50905CDB.7020105@gmail.com> <50919101.5080105@gmail.com> <8A6A4A68-93E0-4465-B062-5ECA9A4E3AE6@gmail.com> Message-Id: <83C862A0-C16C-4E0D-8F9C-DB32238DA724@code-house.org> X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnOiNLPfRExbv3UehP2iWs84IQf1km9AMPEVz0ZfXzPWzLoohvj8rvKw6gTrDNxBd/XRyzP X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_0714629D-1875-4D9C-8555-6BDCED345AC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-2 Wiadomo=B6=E6 napisana przez Guillaume Nodet w dniu 12 lis 2012, o godz. = 21:09: > On Mon, Nov 12, 2012 at 8:30 PM, =A3ukasz Dywicki = wrote: >=20 >> 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. >>=20 >>=20 > Karaf uses jaas login modules already, but that's for the = authentication > part and is kinda unrelated to authorization. That's true, JAAS is used for authentication. You are talking about = authorization but proposed solution do not offer even that. Only one = thing you at this moment which is present is allowing any user execute = any command. Even with extended configuration it still will be = sufficient to limit access only to certain commands. In fact it still = will be mixin of role based access control, where given user or role = have access only to given set of things. Do we really need another = authorization service for that? I doubt we not. If you want to talk about real authorization then we should be able to = limit access to specific bundles. To get a proper authorization we must = go low level and permissions must be an object. Not a string = command:list because it will fail for sure with commands like = start/stop/update which have arguments. Do you really want use syntax = comand:stop:12 to grant privileges? For that you need something mapping = file between roles and permissions plus subject aware of permissions it = holds. Really simple example of mapping roles to permissions you can = find here = http://trac.agavi.org/browser/trunk/samples/app/config/rbac_definitions.xm= l. >> 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. >>=20 >>=20 > The goal isn't really to have this service supported or called by all > projects. Securing the shell commands or the jmx access isn't related = to > ServiceMix, so that does not really solve the problem at hand. > The goal isn't to provide a new generic authorization mechanism, the = real > target is karaf own stuff, mainly the shell commands and later JMX = services > and web console. If it can be opened a bit, that may be a good fit in = some > cases, but again, the main target is not application or messaging = security, > so WS-Security, Camel or ActiveMQ isn't the main target. I think about security in Karaf in terms of portability to other = projects. Do you know that you can not use one JAAS realm and re-use it = in Karaf WebConsole/JMX and ActiveMQ? That's big PITA for users. = Introducing another service for that will not move as to solution. As = said before - we don't need the IAuthService to achieve goal you listed. >> 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. >>=20 >> Login modules configuration is not XML. PermissionAdmin is really = low > level and mostly for code based security, not application level > authorization. I have experimented with the security layer in OSGi, = but I > don't think it's the same use case. > Have you ever seen a web app using JAAS for authorization ? Really, = JAAS > main use case is code level security. The OSGi security layer is at = the > same level: permissions are define to grant access to some code based = on > the calling bundle, so you can deny calls for given bundles. But that = does > not fit the use case here. In the OSGi security layer, the = permissions are > mainly granted based on the code signer, not the JAAS authenticated = user, > so trying to fit in that model is a bad idea imho. >=20 > And again, running in a security manager has a non negligeable = overhead to > running *any* code, so I don't think people will always want to pay = that > cost. I know that login modules are configured in policy files. My point was = that this XML itself can be used by custom login module to assign = permissions for given user. In fact it's mapping of premissions to role, = which is - as I said before - specific to Role Based Access Control. You = right on code execution stuff, but as far as it provides generic = capabilities I see no risk in using it, only benefits. All stuff you = need is to implement custom Permissions and Conditions. You can deploy = local permission configuration with that: ALLOW { [org.apache.karaf.management.CurrentUserPermission "*" ] (org.apache.karaf.management.perm.BundlePermission = "(symbolicName=3Dcom.mycompany.*)" = "install,resolve,start,stop,update,uninstall" ) } "Core User Permission"=20 Just think about possibilities of this mechanism - they are far, far = away from using just wildcards for names. Another thing - If someone is really scary about security then runs = security manager to reduce risks on JVM level and cut off all XSS = posibilities to shutdown VM. Overall point from me is to use specs where are they defined. I can = understand that you are not convinced about JAAS however I can not = accept your comparison to OSGi PermissionAdmin. It was made to run well = in OSGi framework and can be easily separated from signer/location = conditions and used together with JAAS subjects. Best regards, Lukasz >=20 >=20 >> Best regards, >> Lukasz >>=20 >> Wiadomo=B6=E6 napisana przez Guillaume Nodet w dniu 12 lis 2012, o = godz. 14:36: >>=20 >>> 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 >>>>=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 >>>>>>>=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 = >>=20 >>>> < >>>>>>> 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> >>>> < >>>>>>> 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 >>> -- >>> ------------------------ >>> 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 --Apple-Mail=_0714629D-1875-4D9C-8555-6BDCED345AC8--