This is a follow up to part one of my blog regarding setting up Role Based Access Control (RBAC) in JBoss EAP 6 and Wildfly.
Part one can be found HERE.
In Part One of this blog we first looked at what RBAC is and why it's needed. We then set up a number of users and assigned those users to groups with each group having different permissions.
In this follow-up we will look at constraints which allow more fine grained permission setting, scoped roles which allow you to set permissions on individual servers and audit logging which allows you to see who has accessed the management console and what changes they have made.
For the purposes of this blog I will be using the following:
OS - Ubuntu 14
Java - 1.7.0_67
JBoss - EAP 6.3
Although I'm using EAP these instructions should work just the same on Wildfly.
In order to do the practical examples you must have gone through the examples in Part One as the changes made here will follow on from that.
Constraints
Constraints are named sets of access-control configuration for a specified list of resources. RBAC uses a combination of contraints and role permissions to decide if a user is allowed to perform a specific action.
There are two types of constraint, Application constraints and Sensitivity constraints.
Application constraints
Application constraints define which resources, attributes and operations can be accessed by users with the Deployer role.
By default the only constraint that is enabled is core which gives the Deployer role the ability to manage deployments.
Application constraint configuration is in the Management API at:
/core-service=management/access=authorization/constraint=application-classification.
Sensitivity constraints
Sensitivity constraints define who can access resources that are considered to be sensitive. Only users with the Administrator role or the SuperUser role have the ability to make changes to senstive resources.
Sensitivity constraint configuration is in the Management API at:
/core-service=management/access=authorization/constraint=sensitivity-classification.
OK, so lets look at a practical example of setting up a new constraint.
In our original scenario we had a user Bob who was given the deployer role. Now we'd like Bob to be able to alter datasources as it's useful for him to be able to make changes when he's deployed a new app and there are issues.
Start up your JBoss server from Part One.
Log in to the management console as the user Bob.
In the management console, go to Configuration - Connector - Datasources
At the moment Bob in his current Deployer role can only read information regarding datasources, he can't edit the current settings or add or remove datasources.
Now, we could change Bob's role to give him more control but we only really want him to be able to alter datasources, not give him access to everything. This is where we can instead alter the constraints.
First of all cd to the datasources constraint:
cd /core-service=management/access=authorization/constraint=application-classification/type=datasources/
Now, we need to set the configured-application attribute to true.
NOTE - In order to alter the datasource configuration you need to set both the data-source and xa-data-source attributes. Setting just one will not work.
./classification=data-source:write-attribute(name=configured-application,value=true)
./classification=xa-data-source:write-attribute(name=configured-application,value=true)
Now if you go back to the management console you should find that Bob can now edit datasources but does not have access to other resources that an Administrator or SuperUser has.
So, we have seen how we can set up users in groups, give particular users the ability to make changes based on their role and how to extend what that role can do based on individual constraints. But what if you have 100s of servers and we want even more fine-grained control and we want to allow users to only make changes to particular servers?
Scoped Roles
Scoped Roles are roles that you define yourself that allow you to grant the same permissions as the standard roles but apply that to a set of servers rather than all servers. This is done by specifying which server groups or individual hosts that role can make changes to. Once you have defined a scoped role it can be applied to users (or groups of users) the same as any other role.
NOTE - Only users in the SuperUser or Administrator roles can perform this configuration.
Now, the situation we have in our test scenario is that we have a new user Elvis who we want to be administrator but only for a certain set of servers.
First of all lets create a new server and server group and add the server to the group.
In the admin console, go to Domain - Server - Server Groups.
Add a new server group as follows:
Name - Test-Group
Profile - full
Socket Binding - full-sockets
Next, go to Domain - Server - Server Configurations.
Add a new server config as follows:
Name - Test-Server
Server Group - Test-Group
Port Offset - 100
Auto Start - True
Restart the server.
Now, we want to create a new user and give him access only to the configuration of the servers in Test-Group.
Firstly, we need to create our new scoped role:
/core-service=management/access=authorization/server-group-scoped-role=Test-Role:add(base-role=administrator, server-groups=[Test-Group])
Next we need to add our new user. For this use the same add-user.sh script we used in Part One to create the user Elvis.
Now we need to map our user to our new scoped role:
/core-service=management/access=authorization/role-mapping=Test-Role:add
/core-service=management/access=authorization/role-mapping=Test-Role/include=test-admin:add(name=Elvis, type=user)
Now, if you log in to the admin console as the user Elvis you will see you only have access to the configuration of the Test-Group servers (in this case just the one server Test-Server). Hopefully from this you will see how easy it is to set up servers into groups and then to assign users roles that allow them to configure just the servers in certain groups.
Audit Logging
Finally we will set up audit logging to capture administrative actions. Although not strictly a part of RBAC it is very useful to be able to see what changes have been made to a system, when those changes were made and by who, if only so you know who to blame when something goes wrong. ;)
Audit logging is switched off by default so the first thing we will do is to switch it on.
Use the following command to switch on audit logging:
/host=master/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
Now, if you look in JBOSS_HOME/domain/data
You should see a file called audit-log.log. In here you will see one record detailing the change we just made.
Log records can be output to a file, forwarded to a Syslog server or both. By default they are output to file.
This will only switch on audit logging for the domain controller. If you wish to switch on audit logging for all servers run the following:
/host=master/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)
These log files can be found in JBOSS_HOME/domain/servers/<server-name>/data
By default all log entries are stored in JSON format. Before being output to file all log entries are passed through a formatter and a handler. The formatter specifies what the log entries look like whilst the handler handles outputting the record to file or to Syslog.
Well, that's all for now. Hopefully this has been a useful introduction to Role Based Access Control for JBoss. It's a great new addition and something you should definitely consider when setting up JBoss servers.
![]()
Part one can be found HERE.
In Part One of this blog we first looked at what RBAC is and why it's needed. We then set up a number of users and assigned those users to groups with each group having different permissions.
In this follow-up we will look at constraints which allow more fine grained permission setting, scoped roles which allow you to set permissions on individual servers and audit logging which allows you to see who has accessed the management console and what changes they have made.
For the purposes of this blog I will be using the following:
OS - Ubuntu 14
Java - 1.7.0_67
JBoss - EAP 6.3
Although I'm using EAP these instructions should work just the same on Wildfly.
In order to do the practical examples you must have gone through the examples in Part One as the changes made here will follow on from that.
Constraints
Constraints are named sets of access-control configuration for a specified list of resources. RBAC uses a combination of contraints and role permissions to decide if a user is allowed to perform a specific action.
There are two types of constraint, Application constraints and Sensitivity constraints.
Application constraints
Application constraints define which resources, attributes and operations can be accessed by users with the Deployer role.
By default the only constraint that is enabled is core which gives the Deployer role the ability to manage deployments.
Application constraint configuration is in the Management API at:
/core-service=management/access=authorization/constraint=application-classification.
Sensitivity constraints
Sensitivity constraints define who can access resources that are considered to be sensitive. Only users with the Administrator role or the SuperUser role have the ability to make changes to senstive resources.
Sensitivity constraint configuration is in the Management API at:
/core-service=management/access=authorization/constraint=sensitivity-classification.
OK, so lets look at a practical example of setting up a new constraint.
In our original scenario we had a user Bob who was given the deployer role. Now we'd like Bob to be able to alter datasources as it's useful for him to be able to make changes when he's deployed a new app and there are issues.
Start up your JBoss server from Part One.
Log in to the management console as the user Bob.
In the management console, go to Configuration - Connector - Datasources
At the moment Bob in his current Deployer role can only read information regarding datasources, he can't edit the current settings or add or remove datasources.
Now, we could change Bob's role to give him more control but we only really want him to be able to alter datasources, not give him access to everything. This is where we can instead alter the constraints.
First of all cd to the datasources constraint:
cd /core-service=management/access=authorization/constraint=application-classification/type=datasources/
Now, we need to set the configured-application attribute to true.
NOTE - In order to alter the datasource configuration you need to set both the data-source and xa-data-source attributes. Setting just one will not work.
./classification=data-source:write-attribute(name=configured-application,value=true)
./classification=xa-data-source:write-attribute(name=configured-application,value=true)
Now if you go back to the management console you should find that Bob can now edit datasources but does not have access to other resources that an Administrator or SuperUser has.
So, we have seen how we can set up users in groups, give particular users the ability to make changes based on their role and how to extend what that role can do based on individual constraints. But what if you have 100s of servers and we want even more fine-grained control and we want to allow users to only make changes to particular servers?
Scoped Roles
Scoped Roles are roles that you define yourself that allow you to grant the same permissions as the standard roles but apply that to a set of servers rather than all servers. This is done by specifying which server groups or individual hosts that role can make changes to. Once you have defined a scoped role it can be applied to users (or groups of users) the same as any other role.
NOTE - Only users in the SuperUser or Administrator roles can perform this configuration.
Now, the situation we have in our test scenario is that we have a new user Elvis who we want to be administrator but only for a certain set of servers.
First of all lets create a new server and server group and add the server to the group.
In the admin console, go to Domain - Server - Server Groups.
Add a new server group as follows:
Name - Test-Group
Profile - full
Socket Binding - full-sockets
Next, go to Domain - Server - Server Configurations.
Add a new server config as follows:
Name - Test-Server
Server Group - Test-Group
Port Offset - 100
Auto Start - True
Restart the server.
Now, we want to create a new user and give him access only to the configuration of the servers in Test-Group.
Firstly, we need to create our new scoped role:
/core-service=management/access=authorization/server-group-scoped-role=Test-Role:add(base-role=administrator, server-groups=[Test-Group])
Next we need to add our new user. For this use the same add-user.sh script we used in Part One to create the user Elvis.
Now we need to map our user to our new scoped role:
/core-service=management/access=authorization/role-mapping=Test-Role:add
/core-service=management/access=authorization/role-mapping=Test-Role/include=test-admin:add(name=Elvis, type=user)
Now, if you log in to the admin console as the user Elvis you will see you only have access to the configuration of the Test-Group servers (in this case just the one server Test-Server). Hopefully from this you will see how easy it is to set up servers into groups and then to assign users roles that allow them to configure just the servers in certain groups.
Audit Logging
Finally we will set up audit logging to capture administrative actions. Although not strictly a part of RBAC it is very useful to be able to see what changes have been made to a system, when those changes were made and by who, if only so you know who to blame when something goes wrong. ;)
Audit logging is switched off by default so the first thing we will do is to switch it on.
Use the following command to switch on audit logging:
/host=master/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
Now, if you look in JBOSS_HOME/domain/data
You should see a file called audit-log.log. In here you will see one record detailing the change we just made.
Log records can be output to a file, forwarded to a Syslog server or both. By default they are output to file.
This will only switch on audit logging for the domain controller. If you wish to switch on audit logging for all servers run the following:
/host=master/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)
These log files can be found in JBOSS_HOME/domain/servers/<server-name>/data
By default all log entries are stored in JSON format. Before being output to file all log entries are passed through a formatter and a handler. The formatter specifies what the log entries look like whilst the handler handles outputting the record to file or to Syslog.
Well, that's all for now. Hopefully this has been a useful introduction to Role Based Access Control for JBoss. It's a great new addition and something you should definitely consider when setting up JBoss servers.
