Good point David.
Regards
JB
On 08/23/2013 01:00 PM, David Bosschaert wrote:
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é <[email protected]> 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 <[email protected]>**
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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
