karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: Securing shell commands
Date Mon, 12 Nov 2012 12:30:11 GMT
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 <gnodet@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.westerfeld@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 <gnodet@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.pozolotin@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 <gnodet@gmail.com> <gnodet@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.pozolotin@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 <bcanhome@googlemail.com> <
>>> bcanhome@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.pozolotin@gmail.com> <
>>> andrei.pozolotin@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 <gnodet@gmail.com> <gnodet@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.pozolotin@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 <gnodet@gmail.com> <gnodet@gmail.com>
<
>>> gnodet@gmail.com> <gnodet@gmail.com>
>>>>> To: dev@karaf.apache.org, kurt@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 <gnodet@gmail.com>
<
>>> gnodet@gmail.com> <
>>>>> 
>>>>> gnodet@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.westerfeld@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 <gnodet@gmail.com>
<
>>> gnodet@gmail.com>
>>>>> 
>>>>> <gnodet@gmail.com> <gnodet@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.westerfeld@gmail.com> <kurt.westerfeld@gmail.com> <
>>> kurt.westerfeld@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 <gnodet@gmail.com>
<
>>> gnodet@gmail.com> <
>>>>> 
>>>>> gnodet@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


Mime
View raw message