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 Mon, 12 Nov 2012 20:09:38 GMT
On Mon, Nov 12, 2012 at 8:30 PM, Łukasz Dywicki <luke@code-house.org> wrote:

> As far I know you can use JAAS login modules without JVM level security
> manager. It's only metter of creating the login context/module and so on.
> However usage of SecurityManager gives us another big benefit - possibility
> to integrate Karaf security with OSGi level permissions.
>
>
Karaf uses jaas login modules already, but that's for the authentication
part and is kinda unrelated to authorization.


> What I see in another IAuthService is that nobody will support that. Every
> single projects which could be possibly integrated with Karaf will need to
> bridge all security things.  I know you can implement that in Camel or
> ActiveMQ, but from other hand did you get earlier implementation of similar
> service for SMX3? Even if you will have this then in 95% of cases you will
> bridge JAAS subject from Camel to IAuthService in Karaf which will hide
> JAAS. You can not guarantee that xml-security project will support karaf
> security layer. Thus usage of WS-Security will always require 3rd party
> code to be produced. Every time.
> If you would like to do things like integrating security layers from
> different projects to run all together then I think the best place for that
> is ServiceMix, not Karaf - as it was before.
>
>
The goal isn't really to have this service supported or called by all
projects.  Securing the shell commands or the jmx access isn't related to
ServiceMix, so that does not really solve the problem at hand.
The goal isn't to provide a new generic authorization mechanism, the real
target is karaf own stuff, mainly the shell commands and later JMX services
and web console.  If it can be opened a bit, that may be a good fit in some
cases, but again, the main target is not application or messaging security,
so WS-Security, Camel or ActiveMQ isn't the main target.


> The XML structure you shown before looks like configuration of login
> module for me. What we really need is pre-defined list of possible actions
> to execute (in other words permissions), like BundleStopPermission(bundle),
> BundleListPermission(framework/region). Only one standard I know which
> supports that is JAAS.
> We are always running under OSGi. Here we already have a service to use -
> it's called PermissionAdmin. As we are lightweight OSGi container we
> definitely should rely on this, not some custom parts.
>
> Login modules configuration is not XML.   PermissionAdmin is really low
level and mostly for code based security, not application level
authorization.  I have experimented with the security layer in OSGi, but I
don't think it's the same use case.
Have you ever seen a web app using JAAS for authorization ? Really, JAAS
main use case is code level security. The OSGi security layer is at the
same level: permissions are define to grant access to some code based on
the calling bundle, so you can deny calls for given bundles.  But that does
not fit the use case here.  In the OSGi security layer, the permissions are
mainly granted based on the code signer, not the JAAS authenticated user,
so trying to fit in that model is a bad idea imho.

And again, running in a security manager has a non negligeable overhead to
running *any* code, so I don't think people will always want to pay that
cost.


> Best regards,
> Lukasz
>
> Wiadomość napisana przez Guillaume Nodet w dniu 12 lis 2012, o godz. 14:36:
>
> > Could you explain how you would do that with pure JAAS without requiring
> a
> > security manager ?
> > Security manager is not always the best option.  And I haven't seen many
> > projects forcing its use for simple authorization.
> >
> > I agree that xml is not perfect, especially in that case, the main
> reason,
> > but a flat property file with ordering is not easy to write either.
> > Another option would be to use a url which would point to the xml, or
> text
> > base file.  But properties are map based with no ordering guarantee.
> >
> >
> > On Mon, Nov 12, 2012 at 1:30 PM, Łukasz Dywicki <luke@code-house.org>
> wrote:
> >
> >> 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
> >>
> >>
> >
> >
> > --
> > ------------------------
> > 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