karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Role based security for Karaf JMX access
Date Wed, 07 Aug 2013 14:33:23 GMT

It sounds good. But currently, with our JAAS implementation, we have 
users and roles (not groups, even if roles can look like groups).

An user can have multiple roles. For instance, in the default 
users.properties we have:


We don't use the roles currently (in the shell, etc).

The first step that I proposed is to "secure" some commands and shell 
scope depending of a role, and provide a generic service that other 
applications can use.


On 08/07/2013 09:37 AM, Christian Schneider 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/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
>> * role-based access to JMX:
>> https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f
>> Best regards,
>> David
>> davidb@apache.org
>> david@redhat.com
>> david.bosschaert@gmail.com

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message