| created on | July 12, 2022 |
WildFly ships with two authentication providers, the simple provider and the RBAC provider.
RBAC is for Role Based Access Control and provides fine grained access control as opposed to the default authentication provider simple, where any authenticated user in the CLI or web console has all permissions.
In RBAC, three types of entities can be used for access control
Users can be added with the shell script
Users can be mapped to either the ManagementRealm or the ApplicationRealm. The ManagementRealm is used to handle access to management functions in the CLI and the admin web console. The ApplicationRealm is used to handle access to resources by a process, i.e. a process accessing to a bean or a process for deploying apps to the WildFly server.
RBAC is based on seven standard roles:
| role | ressource modification | persistent configuration | audit loggin system |
|---|---|---|---|
| Monitor | read only | read only | no access |
| Operator | runtime state, i.e. server (re)start | read only | no access |
| Deployer | runtime state | only application specific, i.e. can deploy an app but cannot configure the server (*1) | no access |
| Maintainer | runtime state | full read and write access, can modify persistent server config, can deploy apps | no access |
| Administrator | full access | full read and write access | no access |
| Auditor | read only | read only | full read and write access, i.e. can configure audit logging |
| SuperUser | full access | full access | full read and write access |
*1: exceptions to this restriction may apply if a resource that is not part of the app deployment, is application specific. see access control constraints
Before switching to RBAC, at least one user should be mapped the role SuperUser.
mapping a user to the SuperUser role in CLI:
switch on RBAC in CLI:
RBAC defines three different actions to modify resources, for which permissions can be granted or denied: address, read and write.
read and write are self-explanatory. address refers to an action that enables an user to determine if a resource exists or does not exist. Some resource name may be by itself security sensitive information. An example is a security realm resource. It includes the realm name as the last element in the address and this element is part of the data used when creating a hash of a user password. If a user attempts to address a resource for which he or she is not granted the permission to address this resource, the system will respond as if the resource doesn’t exist (i.e. “resource not found”) instead of giving out clues with an error message such as “permission denied”.
To determine whether a given role is granted a permission, the follwoing factors are used:
If a user is assigned to several roles, by default he or she will be granted the union of the permissions of the roles the user is assigned to. This default behaviour can be changed on a global basis to deny any permission, if a clash between permissions in two or more roles is detected, i.e. as in the union of the Operator and the Auditor role.
The more restricitve mode can be enabled in the CLI with:
The default (permissive) mode can be enabled in the CLI with: