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... Cheers, David On 7 August 2013 08:37, Christian Schneider <[email protected]> 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, [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/** >> 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 >> >> [email protected] >> [email protected] >> [email protected] >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
