karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Role based security for Karaf JMX access
Date Wed, 07 Aug 2013 13:33:23 GMT
Hi Ioannis, Christian,

Thanks for the feedback!
Yes, providing similar Access Control for the Karaf shell is also on my
list. Hopefully I can look at that in the near future.

WRT to groups versus nested roles. I thought about that too. You could
achieve the same effect with roles if they can subsume other roles. This
would require a recursive/nested definition of roles and I'm not sure this
is universally supported by all security back-ends. The users/groups/roles
combination seems extremely common and supported by many systems. It's also
a little bit simpler in that there is no recursion involved, which might
make it easier to map it to certain types of back-end stores...
Therefore I opted for groups, I hope everyone can live with that...

> Btw. I am planning to add some jaas based authentication and role based
security to CXF that might also profit from your addition.

Cool, yes with that a CXF might set JAAS principals in the current context,
which can then be picked up by the JMX guard...



On 7 August 2013 08:37, Christian Schneider <chris@die-schneider.net> wrote:

> Group and Role based security sounds like a good addition to karaf.
> I am not sure if it is necessary to distinguish groups and roles though.
> Can't we just support adding roles into roles (or groups into groups)?
> This should provide the same additional layer of abstraction.
> Btw. I am planning to add some jaas based authentication and role based
> security to CXF that might also profit from your addition.
> Another thing that seems related is xacml support in cxf. Perhaps we could
> define some common Policy Decision Point interface that can be implemented
> using
> either your implementation or an xacml based pdp.
> Christian
> On 06.08.2013 12:22, davidb@apache.org wrote:
>> Hi all,
>> I have started an implementation of Role based security for JMX access
>> into
>> Karaf.
>> Up until now, remote JMX access was guarded by one role. If you had that
>> role you could access everything. With my changes you can define roles
>> (ACLs) per MBean, per method or based on arguments to an MBean invocation.
>> There are also wildcards that can be used to define general rules for all
>> MBeans which provide default behaviour for any MBean which doesn't have a
>> specific ACL.
>> It works like this.
>> The bin/karaf launch script sets -Djavax.management.builder.**initial to
>> specify a Karaf-provided MBean Server Builder. This builder
>> guards/intercepts any MBean invocations and checks the roles of the
>> current
>> user for the current invocation. These roles are set through the existing
>> Karaf JAAS intergration. If the current user doesn't have the required
>> roles an exception is thrown and the invocation does not proceed.
>> ACLs for the various MBeans are defined alongside other Karaf
>> configuration
>> in the cfg/ directory and read through OSGi ConfigAdmin. The PID/file name
>> is based on the MBean Object Name, for example an MBean called
>> org.apache.karaf:type=bundles,**name=root is mapped to a file
>> jmx.acl.org.apache.karaf.**bundles.root.cfg. This file can contain an ACL
>> like this:
>>    list : viewer, manager
>>    restart : manager
>>    stop(java.lang.String)["0"] : admin # String argument match
>>    stop(java.lang.String)[/([1-4]**)?[0-9]/] : admin # Regexp argument
>> match
>>    stop(java.lang.String) : manager # any other arguments match this
>> If no rules can be found for the current invocation the system will search
>> in a higher level cfg file, with as highest level jmx.acl.cfg which
>> contains the following 'catchall' rules.
>>    get* : viewer
>>    is* : viewer
>>    set* : admin
>>    * : admin
>> Whenever a matching rule is found, that is used and the code doesn't look
>> any further. So the most specific definition wins.
>> Certain rules need to have broad access, e.g. an admin role. It's not
>> practical to have to specify 'admin' as a role with every single access
>> control declaration. For this I have introduced groups. While other
>> solutions might be possible, groups are widely supported in security
>> systems so I used those.
>> E.g. to address the 'admin' use-case above you might have a user (joe) who
>> needs rights to every MBean in the system. For this you add joe to the
>> AdminGroup. The AdminGroup then has every role that is defined in the
>> system. It's not magic, because every time you add a new role to the
>> system
>> you need to update the AdminGroup, but it's manageable.
>> Finally I added a special MBean org.apache.karaf.security that allows you
>> to find out whether the current user has the right roles to use a certain
>> mbean or invoke a certain invocation. This can be used when building a
>> management console/GUI to hide things that map to operations that the
>> current user has no right to anyway. It's not 100% watertight in the sense
>> that a specific role can be specified for a specific value (e.g. only
>> 'admin' can stop bundle 0), so there is still a chance that the attempted
>> invocation is rejected, but in general it should be a help to building
>> smart consoles. BTW I'm planning to add bulk operations to this one,
>> that's
>> still a to-do.
>> Couple of notes:
>> * It's all very pluggable. You can switch JAAS back-ends, ConfigAdmin
>> implementations, or even the whole JMX guard implementation (which is not
>> very big) by specifying another MBean Server Builder.
>> * You can log into JMX without credentials when using a local JConsole or
>> directly in the process. When no credentials are found the JMX guard will
>> refuse any operation.
>> * I added a bunch of Karaf Console commands to administer JAAS groups.
>> * JAAS Groups are not yet supported by all JAAS/Karaf backends. I added it
>> to the PropertiesBackingEngine. They can be added gradually.
>> * The idea is to also add Role-based Access to the Karaf Console commands
>> at some point going forward, but that's a separate piece of work...
>> So... the question is: would the Karaf community be interested in this
>> Role
>> based JMX security? I would be more than happy to donate it. My current
>> implementation can be viewed in here:
>> * addition of group support:
>> https://github.com/bosschaert/**karaf/commit/**
>> 6598f088c53aa5bce217cdc2e066a9**6f8f3d5d37<https://github.com/bosschaert/karaf/commit/6598f088c53aa5bce217cdc2e066a96f8f3d5d37>
>> * role-based access to JMX:
>> https://github.com/bosschaert/**karaf/commit/**
>> bfee2d1b2c736c9b54cbfce8e4b07c**8cfadf980f<https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f>
>> Best regards,
>> David
>> davidb@apache.org
>> david@redhat.com
>> david.bosschaert@gmail.com
> --
> Christian Schneider
> http://www.liquid-reality.de
> Open Source Architect
> http://www.talend.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message