You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by da...@apache.org on 2013/08/06 12:22:39 UTC
Role based security for Karaf JMX access
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/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
* role-based access to JMX:
https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f
Best regards,
David
davidb@apache.org
david@redhat.com
david.bosschaert@gmail.com
Re: Role based security for Karaf JMX access
Posted by Ioannis Canellos <io...@gmail.com>.
Hi David,
There have been long discussions in the past about more fine grained
security than what we currently have.
In most cases the discussion has been focused around commands but
there is a clear need for more fine grained control over jmx too.
With the quick glimpse at the commits, I think that the approach makes
a lot of sense to me and I'd love to see those ideas being part of
Karaf.
On Tue, Aug 6, 2013 at 1:22 PM, <da...@apache.org> 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/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
> * role-based access to JMX:
> https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f
>
> Best regards,
>
> David
>
> davidb@apache.org
> david@redhat.com
> david.bosschaert@gmail.com
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: Role based security for Karaf JMX access
Posted by Freeman Fang <fr...@gmail.com>.
Awesome, this fine-grained security is what Karaf want for a long time.
Adding it to the JMX access definitely is a good start, also looking forward to this improvement on Karaf console command.
+1 for all the input here.
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋
On 2013-8-6, at 下午6:22, davidb@apache.org 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/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
> * role-based access to JMX:
> https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f
>
> Best regards,
>
> David
>
> davidb@apache.org
> david@redhat.com
> david.bosschaert@gmail.com
Re: Role based security for Karaf JMX access
Posted by David Bosschaert <da...@gmail.com>.
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 <ch...@die-schneider.net> 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, davidb@apache.org 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
>>
>> davidb@apache.org
>> david@redhat.com
>> david.bosschaert@gmail.com
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Role based security for Karaf JMX access
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi David,
thanks for the update, it sounds good to me !!
How can I help on that ?
Maybe we can explore some options to leverage other projects (like
Apache Syncope for instance).
Regards
JB
On 08/07/2013 05:11 PM, David Bosschaert wrote:
> Hi JB,
>
> On 7 August 2013 15:33, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> Hi,
>>
>> It sounds good. But currently, with our JAAS implementation, we have users
>> and roles (not groups, even if roles can look like groups).
>
>
>
>> An user can have multiple roles. For instance, in the default
>> users.properties we have:
>>
>> user=password,role1,role2,**role3,...
>>
>
> Right, and I'm proposing to extend that to include groups. So a user can
> have roles directly, or be part of a group. This group can then also have
> roles. When that user logs in he gets the union of all the roles associated
> with all of the groups (s)he is in and the roles directly associated with
> this user.
>
> This makes it more manageable to define ACLs in terms of roles and also
> have high-privilege groups such as an AdminGroup that have many roles.
>
> You can see how I propose to add groups to the mix here:
> https://github.com/bosschaert/karaf/commit/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
>
>
>> We don't use the roles currently (in the shell, etc).
>>
>> The first step that I proposed is to "secure" some commands and shell
>> scope depending of a role, and provide a generic service that other
>> applications can use.
>
>
> Right - this email trail was to kick off securing the JMX management API.
> I'm hoping to look at securing the shell commands soon ;)
>
> As I think the general feeling on this mailing list is supportive of my
> proposed contribution, I've created two JIRAs for this:
>
> Add support for JAAS groups:
> https://issues.apache.org/jira/browse/KARAF-2434
> Add Role-based access to JMX:
> https://issues.apache.org/jira/browse/KARAF-2435
>
> Is there already a JIRA for adding role-based security the console? If not
> I can add one...
>
> Cheers,
>
> David
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Role based security for Karaf JMX access
Posted by David Bosschaert <da...@gmail.com>.
Hi JB,
On 7 August 2013 15:33, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi,
>
> It sounds good. But currently, with our JAAS implementation, we have users
> and roles (not groups, even if roles can look like groups).
> An user can have multiple roles. For instance, in the default
> users.properties we have:
>
> user=password,role1,role2,**role3,...
>
Right, and I'm proposing to extend that to include groups. So a user can
have roles directly, or be part of a group. This group can then also have
roles. When that user logs in he gets the union of all the roles associated
with all of the groups (s)he is in and the roles directly associated with
this user.
This makes it more manageable to define ACLs in terms of roles and also
have high-privilege groups such as an AdminGroup that have many roles.
You can see how I propose to add groups to the mix here:
https://github.com/bosschaert/karaf/commit/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
> We don't use the roles currently (in the shell, etc).
>
> The first step that I proposed is to "secure" some commands and shell
> scope depending of a role, and provide a generic service that other
> applications can use.
Right - this email trail was to kick off securing the JMX management API.
I'm hoping to look at securing the shell commands soon ;)
As I think the general feeling on this mailing list is supportive of my
proposed contribution, I've created two JIRAs for this:
Add support for JAAS groups:
https://issues.apache.org/jira/browse/KARAF-2434
Add Role-based access to JMX:
https://issues.apache.org/jira/browse/KARAF-2435
Is there already a JIRA for adding role-based security the console? If not
I can add one...
Cheers,
David
Re: Role based security for Karaf JMX access
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
It sounds good. But currently, with our JAAS implementation, we have
users and roles (not groups, even if roles can look like groups).
An user can have multiple roles. For instance, in the default
users.properties we have:
user=password,role1,role2,role3,...
We don't use the roles currently (in the shell, etc).
The first step that I proposed is to "secure" some commands and shell
scope depending of a role, and provide a generic service that other
applications can use.
Regards
JB
On 08/07/2013 09:37 AM, Christian Schneider 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, davidb@apache.org 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/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
>>
>> * role-based access to JMX:
>> https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f
>>
>>
>> Best regards,
>>
>> David
>>
>> davidb@apache.org
>> david@redhat.com
>> david.bosschaert@gmail.com
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Role based security for Karaf JMX access
Posted by Christian Schneider <ch...@die-schneider.net>.
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, davidb@apache.org 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/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
> * role-based access to JMX:
> https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f
>
> Best regards,
>
> David
>
> davidb@apache.org
> david@redhat.com
> david.bosschaert@gmail.com
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com