Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: pass (nike.apache.org: domain of gnodet@gmail.com designates
 74.125.83.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8A6A4A68-93E0-4465-B062-5ECA9A4E3AE6@gmail.com>
References: 
 <CAEQV+EFjAwDLzV-9VZTGNFgjuKxr=1g-3dHZ=w6g_8uegj1=KA@mail.gmail.com>
	<C5529A79-DC4E-4836-B251-2699ED33B620@gmail.com>
	<CAEQV+EEA7sbSpW_00-MyPqE3rvX7=Eyw_rO-82EY89ZN1WqP2g@mail.gmail.com>
	<CAMedqW324DtW+bx+WyPtn6z1F4bY2atHyogkGp7du1Z6C5902w@mail.gmail.com>
	<CAEQV+EE-Uv38Vj93g=xQTW_mZZLh5Ma_8uZ+oGmkj9yavFweDg@mail.gmail.com>
	<CAEQV+EEcxWhwSmQ8gwSiaNs3vxue2AEmtGvNZPg9T0ZFvx5sGg@mail.gmail.com>
	<50903167.1020409@gmail.com>
	<CAEQV+EHna-zvsdqi16v=p2TfdXgbMQA1GbDFg2WSuPTHWSCoew@mail.gmail.com>
	<50904429.9030708@gmail.com>
	<CAD0r13cQwOE+F22zQeOY5vZbz5vVEfvst17JV3n8RJzvAOrJpg@mail.gmail.com>
	<50905CDB.7020105@gmail.com>
	<CAEQV+EGx55R-BBsZ8iqe444YUJ+yiNZaMm36+wrCJAmfkX_-iQ@mail.gmail.com>
	<50919101.5080105@gmail.com>
	<CAEQV+EEqhHw9tHr=E2am7TYQsindqOh8oMzw+MW6xfTNs3akFw@mail.gmail.com>
	<8A6A4A68-93E0-4465-B062-5ECA9A4E3AE6@gmail.com>
Date: Fri, 2 Nov 2012 08:28:31 +0100
Message-ID: 
 <CAEQV+EERapS0GxjK8zuJ_ZQgYbPw4d24CDOP0d44e4iaNZ=pSA@mail.gmail.com>
Subject: Re: Securing shell commands
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@karaf.apache.org
Content-Type: multipart/alternative; boundary=047d7b621f542be94f04cd7e1553

--047d7b621f542be94f04cd7e1553
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7b621f542be94f04cd7e1553--