Java Reference
In-Depth Information
Finally, we have roles that cover multiple areas of the server's functionality. Every role
has a set of permissions assigned and some of them are additionally constrained (for in-
stance, to allow you to configure modifications in only specific subsystems such as data
sources). A list of built-in roles is available in the following table:
Sensitive data (pass-
words and auditing)
Role
Permissions
Monitor
Read-only access to configuration and runtime state.
No access.
All permissions of
Monitor
. This role can restart the server, control JMS destination, and
database connection pools. It cannot modify the configuration.
Operator
No access.
All permissions of
Operator
. This role can modify the configuration (including deploying
new applications).
No access.
Maintainer
All permissions of
Maintainer
, but with restrictions on deploying new applications (cannot
change the configuration of the server).
Deployer
No access.
Read/write access. No ac-
cess to the audit system.
Administrator
All permissions of
Maintainer
.
Read-only access. Full ac-
cess to the auditing sys-
tem.
All permissions of
Monitor
.
Auditor
Everything is permitted. The administrator known from JBoss AS 7 and the simple strategy
in WildFly. Also, this is the default role for a local user (connecting from a localhost).
Full access.
Super User
Besides relying on the group-role mapping mechanism, you have another option to assign
users to roles. You can use the
Administration/Users
screen in the admin console to dir-
ectly assign a user to a role (be sure to select
Include
as the type). Assign the
Super-
User
role now to your current user using the
Add
button. Additionally, you can use
Ad-
ministration/Groups
to add our newly created
TestGroup
to, for instance, the
Mon-
itor
role.
Our configuration is now in place; try and check it out. To switch to the RBAC strategy,
we will need to issue the following command using the CLI interface:
