RBAC (Role Based Access Control) in EAP 6.2 – Part I

New post. Recently I’ve been “forced” to upgrade this blog more often, and I’ll hope not something casual but becomes habit ūüėČ

 

This post will discuss how to configure security in Web Management Console and CLI Management console restricting access depending on user role has. This will do with RBAC, which is defined on Security Guide as:

Is a mechanism for specifying a set of permissions for management users. It allows multiple users to share responsibility for managing JBoss EAP 6.2 servers without each of them requiring unrestricted access. By providing “separation of duties” for management users, JBoss EAP 6.2 makes it easy for an organization to spread responsibility between individuals or groups without granting unnecessary privileges. This ensures the maximum possible security of your servers and data while still providing flexibility for configuration, deployment, and management.

RBAC offers 7 Profiles (roles) that restrict the functions that a user can do:

  • Monitor: Users of the Monitor role have the fewest permissions and can only read the current configuration and state of the server. This role is intended for users who need to track and report on the performance of the server. Monitors cannot modify server configuration nor can they access sensitive data or operations.
    .
  • Operator: The Operator role extends the Monitor role by adding the ability to modify the runtime state of the server. This means that Operators can reload and shutdown the server as well as pause and resume JMS destinations. The Operator role is ideal for users who are responsible for the physical or virtual hosts of the application server so they can ensure that servers can be shutdown and restarted corrected when needed. Operators cannot modify server configuration or access sensitive data or operations.
  • Maintainer:¬†The Maintainer role has access to view and modify runtime state and all configuration except sensitive data and operations. The Maintainer role is the general purpose role that doesn’t have access to sensitive data and operation. The Maintainer role allows users to be granted almost complete access to administer the server without giving those users access to passwords and other sensitive information.
    Maintainers cannot access sensitive data or operations.
  • Deployer:¬†The Deployer role has the same permissions as the Monitor, but can modify configuration and state for deployments and any other resource type enabled as an application resource.
  • Auditor:¬†The Auditor role has all the permissions of the Monitor role and can also view (but not modify) sensitive data, and has full access to the audit logging system. The Auditor role is the only role other than SuperUser that can access the audit logging system. Auditors cannot modify sensitive data or resources. Only read access is permitted.
  • Administrator: The Administrator role has unrestricted access to all resources and operations on the server except the audit logging system. Administrator is the only role (except SuperUser) that has access to sensitive data and operations. This role can also configure the access control system. The Administrator role is only required when handling sensitive data or configuring users and roles. Administrators cannot access the audit logging system and cannot change themselves to the Auditor or SuperUser role.
  • Superuser:¬†The SuperUser role has no restrictions and has complete access to all resources and operations of the server including the audit logging system. This role is equivalent to the administrator users of earlier versions of JBoss EAP 6 (6.0 and 6.1). If RBAC is disabled, all management users have permissions equivalent to the SuperUser role.

 

This matrix shows the different roles and the resources they have access to:

Roles permissions RBAC matrix

Roles permissions RBAC matrix

The Web Management Console gives us the simplest tools to configure RBAC, but at this point it’s disabled and can only be enabled by CLI Console. This CLI command enables RBAC:

[standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9999 /] /:reload
{
"outcome" => "success",
"result" => undefined
}

Now we RBAC enabled, but if we have not added any user role to admin, we can not access the Web console. Of course, we could do it, but it’s fun to see how we can do it in CLI Console.
Next instruction define how to do it:

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)

Where ROLENAME will be user assigned role, USERNAME the user name and ALIAS  be a unique name that we reference this assignment so that Red Hat is advised to be: user-NAME.

Let’s take a look to this example where we’ll configure admin user with superuser rol:

[standalone@localhost:9999 /] /core-service=management/access=authorization/role-mapping=SuperUser/include=user-admin:add(name=admin,type=USER)
{"outcome" => "success"}

Now let’s access the Web Console and configure users as needed, adding roles and configuring user groups, but this will be in the next release.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.