karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt Westerfeld <kurt.westerf...@gmail.com>
Subject Re: Securing shell commands
Date Tue, 30 Oct 2012 14:29:59 GMT
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> 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>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> 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 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