Awesome, this fine-grained security is what Karaf want for a long time. Adding it to the JMX access definitely is a good start, also looking forward to this improvement on Karaf console command. +1 for all the input here. －－－－－－－－－－－－－ Freeman(Yue) Fang
Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-8-6, at 下午6:22, [email protected] 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 > > [email protected] > [email protected] > [email protected]
