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 21:39:00 GMT

Wiadomość napisana przez Guillaume Nodet w dniu 12 lis 2012, o godz. 21:09:

> 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.

That's true, JAAS is used for authentication. You are talking about authorization but proposed
solution do not offer even that. Only one thing you at this moment which is present is allowing
any user execute any command. Even with extended configuration it still will be sufficient
to limit access only to certain commands. In fact it still will be mixin of role based access
control, where given user or role have access only to given set of things. Do we really need
another authorization service for that? I doubt we not.
If you want to talk about real authorization then we should be able to limit access to specific
bundles. To get a proper authorization we must go low level and permissions must be an object.
Not a string command:list because it will fail for sure with commands like start/stop/update
which have arguments. Do you really want use syntax comand:stop:12 to grant privileges? For
that you need something mapping file between roles and permissions plus subject aware of permissions
it holds. Really simple example of mapping roles to permissions you can find here http://trac.agavi.org/browser/trunk/samples/app/config/rbac_definitions.xml.

>> 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.

I think about security in Karaf in terms of portability to other projects. Do you know that
you can not use one JAAS realm and re-use it in Karaf WebConsole/JMX and ActiveMQ? That's
big PITA for users. Introducing another service for that will not move as to solution. As
said before - we don't need the IAuthService to achieve goal you listed.

>> 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.

I know that login modules are configured in policy files. My point was that this XML itself
can be used by custom login module to assign permissions for given user. In fact it's mapping
of premissions to role, which is - as I said before - specific to Role Based Access Control.
You right on code execution stuff, but as far as it provides generic capabilities I see no
risk in using it, only benefits. All stuff you need is to implement custom Permissions and
Conditions. You can deploy local permission configuration with that:

ALLOW {
    [org.apache.karaf.management.CurrentUserPermission "*" ]
    (org.apache.karaf.management.perm.BundlePermission "(symbolicName=com.mycompany.*)" "install,resolve,start,stop,update,uninstall"
)
} "Core User Permission" 

Just think about possibilities of this mechanism - they are far, far away from using just
wildcards for names.

Another thing - If someone is really scary about security then runs security manager to reduce
risks on JVM level and cut off all XSS posibilities to shutdown VM.
Overall point from me is to use specs where are they defined. I can understand that you are
not convinced about JAAS however I can not accept your comparison to OSGi PermissionAdmin.
It was made to run well in OSGi framework and can be easily separated from signer/location
conditions and used together with JAAS subjects.

Best regards,
Lukasz

> 
> 
>> 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