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, dav...@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
dav...@apache.org
da...@redhat.com
david.bosscha...@gmail.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
