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 <gno...@gmail.com> 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 <kurt.westerf...@gmail.com
>>> 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 <gno...@gmail.com> 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 <
>>>> andrei.pozolo...@gmail.com> 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 <gno...@gmail.com> <gno...@gmail.com>
>>>>> To: dev@karaf.apache.org
>>>>> 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 <
>>> andrei.pozolo...@gmail.com> 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 <bcanh...@googlemail.com> <
>>> bcanh...@googlemail.com>
>>>>> To: dev@karaf.apache.org
>>>>> 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 <andrei.pozolo...@gmail.com> <
>>> andrei.pozolo...@gmail.com>:
>>>>>
>>>>> 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 <gno...@gmail.com> <gno...@gmail.com>
>>>>> To: dev@karaf.apache.org
>>>>> 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 <
>>> andrei.pozolo...@gmail.com> 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 <gno...@gmail.com> <gno...@gmail.com> <
>>> gno...@gmail.com> <gno...@gmail.com>
>>>>> To: dev@karaf.apache.org, k...@westerfeld.com
>>>>> 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 <gno...@gmail.com> <
>>> gno...@gmail.com> <
>>>>>
>>>>> gno...@gmail.com> 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 <
>>>>>
>>>>> kurt.westerf...@gmail.com> 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 <gno...@gmail.com> <
>>> gno...@gmail.com>
>>>>>
>>>>> <gno...@gmail.com> <gno...@gmail.com>
>>>>>
>>>>> 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<
>>>>>
>>>>> kurt.westerf...@gmail.com> <kurt.westerf...@gmail.com> <
>>> kurt.westerf...@gmail.com>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 <gno...@gmail.com> <
>>> gno...@gmail.com> <
>>>>>
>>>>> gno...@gmail.com>
>>>>>
>>>>> 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
