I don't think there's any plan for such level of access control for the admin console. I haven't seen any related JIRAs or discussions.
I am currently looking to add some simple role based permissions to the management API which will control what users of the admin console can actually do - to start with I am looking for something fairly coarse grained.
One thing I would find very useful from users of AS7 is some listings of the actual roles their administrators would fit into and the tasks they perform so I can use this as a basis for the coarse permissions.
I was thinking in something like
Operator = Can do deploys and configure datasources
Administrator = Can change all the settings on the app server
Developer/User = Can do deploys (i.e. wars, ears, etc)
A readonly user would also be nice. Can be used for monitoring and checking settings.
Something related: will there be a readonly user for jmx and cli for monitoring?
At the moment we are just finishing off making remote access to JMX accessible over Remoting - this is going to mean that the access to JMX can be secured using the exact same mechanisms as we use for the management interfaces so the users will be the same. When you say read only access to JMX are you talking about read only access for the MBeans or are you referring to where the domain model is exposed over JMX?
At this point I am focussing on the security for domain management itself, however one of main reasons we are doing this is so that we can follow up and use a consistent scheme for authentication and authorization across all management entry points.
For the authorization checks we are implementing them server side after the interface specific handling, this means that whatever is implemented server side is going to be applicable equally to all clients so both the web based admin console and the CLI will have the same authorization restrictions, if you write your own client to perform some tasks that would also be subject to exactly the same authorization checks regardless of if your client uses the HTTP interface or the Native interface.
The roles listed so far definately fit with the set of standard roles I was starting to consider, I would say I would probably expand the operator role to maybe cover all subsystems that have resources defined within them unless we wanted different operators i.e. they woul also be able to define JMS destinations and JAAS security domains.
Darran Lofthouse wrote:
When you say read only access to JMX are you talking about read only access for the MBeans or are you referring to where the domain model is exposed over JMX?
I'm talking about read only access to everything that's accessible over jmx, the domain model that's exposed over JMX and any other MBeans. Basically everything that could be used to monitor a JBoss server via jconsole or any other JMX capable monitoring tool (Nagios, Zenoss, Hyperic, RHQ etc). Why is that important?
I would define the operator role as someone who can stop/start/restart stuff, empty queues or move messages in the messaging subsystem etc. and would require an admin user to manipulate any configuration.
Why is that important?
The reason this is important is because I am placing the authorization checks close to the item being secured, i.e. the domain management authoriziation checks are to be performed server side before the operation is executed.
Architecturay there is then the integration making the domain model accessible over JMX and then the MBean server exposing the actual MBeans. As the MBean calls to the domain model are passed to the domain management tier any authorization checks in the domain management tier will apply equally to invocations coming in over JMX and over the domain management inferfaces so a users view and capabilities will be consistent - however this does not cover general authorization for access to the MBeanServer so I will review that separately.
Overall I am trying to avoid situations where we implement client / transport specific authorization checks that lead to situations where an end user has different capabilities depending on how they access the server.
Is this work completed and slated to be included in an upcoming JBoss release?
My company would like to allow the developers on our production support team to access to the JBoss Web Management Console, but we cannot due to the separation of duties that exists in our shop. In our shop, application updates are normally deployed to production by a build manager - not by the developer(s) who updated the code. Developers do, however, need to be able to monitor the current state of the AS and see what has been deployed, but they may not change what has been deployed (except in "break-the-glass" situations).
Any updates on this.