karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Some thoughts around adding security for Karaf Shell Commands
Date Fri, 23 Aug 2013 10:43:18 GMT
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.



On 08/23/2013 10:41 AM, David Bosschaert wrote:
> Hi Christian,
> On 22 August 2013 23:14, Christian Schneider <chris@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é
Talend - http://www.talend.com

View raw message