karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Securing shell commands
Date Tue, 06 Nov 2012 10:14:35 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message