karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Some thoughts around adding security for Karaf Shell Commands
Date Fri, 23 Aug 2013 08:41:24 GMT
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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message