That may be true for the Karaf MBeans but there are also other MBeans in the system. For example ones provided by the JVM. As an example take the MBean with the following object name: connector:name=rmi It is registered by the JVM and not through OSGi services and has a few operations (start(), stop()). By purely having the ACLs go through the service registry model you would not be able to prevent anyone from calling stop() on that mbean...
It's just an example. Another example would be when an OSGi bundle registers MBeans directly (not through the WhiteBoard pattern). With the approach I suggest in KARAF-2435 you can secure any JMX operation, regardless of whether it's implemented as an OSGi service or not... Cheers, David On 23 August 2013 11:43, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi guys, > > @David, on trunk (3.0.0-SNAPSHOT), Karaf uses Aries JMX for MBean > registration. Aries JMX looks up for MBeans exposed as OSGi services. So I > think we can leverage it. > > WDYT ? > > Regards > JB > > > On 08/23/2013 10:41 AM, David Bosschaert wrote: > >> Hi Christian, >> >> On 22 August 2013 23:14, Christian Schneider <ch...@die-schneider.net>** >> wrote: >> >> Sounds great. I have not yet looked into it in detail but the concept >>> sounds decent. >>> >>> One thing you should keep in mind is to make the authorization >>> exchangeable. For example at Talend we provide an xacml based pdp. So it >>> would be great to have a hook wehere we can plug this in to >>> do the auth decisions. Personally I am not a fan of xacml but this shows >>> that different organizations would probably like to treat this >>> differently. >>> >>> >> What I did provides the authorization roles completely through >> ConfigAdmin. >> Which is pluggable in a number of ways: in Karaf we use the Felix Config >> admin which allows the registration of additional configuration providers. >> You can also replace the Config Admin Service itself to provide the info >> from another place... >> I guess we can always add more pluggability if that's needed. >> >> >> The way round your aproach sounds much more maintainable than xacml. So >>> it >>> might even be interesting to attach a pdp to your authorization impl :-) >>> >>> >> :) >> >> >> I have one other idea. How about doing the authorization for jmx and >>> commands only on the service level? At least in karaf 3 both use the same >>> services so securing only the service instead of jmx and commands would >>> reduce the number of config settings needed. >>> >>> For example: >>> jmx: featureJMXBean.install(****feature) >>> >>> command: feature:install <feature> >>> >>> Both would be secured by simply securing the FeatureService. >>> >>> >> The problem with this is that there are still JMX APIs that aren't >> provided >> as OSGi services so that would leave a pretty big hole in the security if >> you ask me... >> For those cases where a single Service covers both JMX and the console we >> could use a single security point (that would be just a matter of >> configuring it that way), but I think that we still need the direct JMX >> security to make sure people can't do any damage through any of the >> non-OSGi-Service MBeans... >> >> >> One thing I am not sure about btw. is doing too much magic behind the >>> scenes. Like the config admin config you described that causes other >>> configs to be created on the fly. Perhaps we find a simpler model that >>> also >>> works. Currently I do not have a good idea how to handle it though. >>> >>> >> I agree. We need to find the balance between simplicity and ease-of-use. >> If >> you think of a simpler way without configuration generation that doesn't >> make the thing horrilbly hard to use for commands I'd love to hear it. >> >> Cheers, >> >> David >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
