Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 8. Security authorization with role-based access control

Role-based access control (RBAC) capabilities use different permissions levels to restrict user interactions with Data Grid.

Note

For information on creating users and configuring authorization specific to remote or embedded caches, see:

8.1. Data Grid user roles and permissions

Data Grid includes several roles that provide users with permissions to access caches and Data Grid resources.

Role	Permissions	Description
`admin`	ALL	Superuser with all permissions including control of the Cache Manager lifecycle.
`deployer`	ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR, CREATE	Can create and delete Data Grid resources in addition to `application` permissions.
`application`	ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR	Has read and write access to Data Grid resources in addition to `observer` permissions. Can also listen to events and execute server tasks and scripts.
`observer`	ALL_READ, MONITOR	Has read access to Data Grid resources in addition to `monitor` permissions.
`monitor`	MONITOR	Can view statistics via JMX and the `metrics` endpoint.

Additional resources

8.1.1. Permissions

User roles are sets of permissions with different access levels.

Table 8.1. Cache Manager permissions
Permission	Function	Description
CONFIGURATION	`defineConfiguration`	Defines new cache configurations.
LISTEN	`addListener`	Registers listeners against a Cache Manager.
LIFECYCLE	`stop`	Stops the Cache Manager.
CREATE	`createCache`, `removeCache`	Create and remove container resources such as caches, counters, schemas, and scripts.
MONITOR	`getStats`	Allows access to JMX statistics and the `metrics` endpoint.
ALL	-	Includes all Cache Manager permissions.

Table 8.2. Cache permissions
Permission	Function	Description
READ	`get`, `contains`	Retrieves entries from a cache.
WRITE	`put`, `putIfAbsent`, `replace`, `remove`, `evict`	Writes, replaces, removes, evicts data in a cache.
EXEC	`distexec`, `streams`	Allows code execution against a cache.
LISTEN	`addListener`	Registers listeners against a cache.
BULK_READ	`keySet`, `values`, `entrySet`, `query`	Executes bulk retrieve operations.
BULK_WRITE	`clear`, `putAll`	Executes bulk write operations.
LIFECYCLE	`start`, `stop`	Starts and stops a cache.
ADMIN	`getVersion`, `addInterceptor*`, `removeInterceptor`, `getInterceptorChain`, `getEvictionManager`, `getComponentRegistry`, `getDistributionManager`, `getAuthorizationManager`, `evict`, `getRpcManager`, `getCacheConfiguration`, `getCacheManager`, `getInvocationContextContainer`, `setAvailability`, `getDataContainer`, `getStats`, `getXAResource`	Allows access to underlying components and internal structures.
MONITOR	`getStats`	Allows access to JMX statistics and the `metrics` endpoint.
ALL	-	Includes all cache permissions.
ALL_READ	-	Combines the READ and BULK_READ permissions.
ALL_WRITE	-	Combines the WRITE and BULK_WRITE permissions.

Additional resources

Data Grid Security API

8.1.2. Role and permission mappers

Data Grid implements users as a collection of principals. Principals represent either an individual user identity, such as a username, or a group to which the users belong. Internally, these are implemented with the javax.security.auth.Subject class.

To enable authorization, the principals must be mapped to role names, which are then expanded into a set of permissions.

Data Grid includes the PrincipalRoleMapper API for associating security principals to roles, and the RolePermissionMapper API for associating roles with specific permissions.

Data Grid provides the following role and permission mapper implementations:

Cluster role mapper: Stores principal to role mappings in the cluster registry.
Cluster permission mapper: Stores role to permission mappings in the cluster registry. Allows you to dynamically modify user roles and permissions.
Identity role mapper: Uses the principal name as the role name. The type or format of the principal name depends on the source. For example, in an LDAP directory the principal name could be a Distinguished Name (DN).
Common name role mapper: Uses the Common Name (CN) as the role name. You can use this role mapper with an LDAP directory or with client certificates that contain Distinguished Names (DN); for example cn=managers,ou=people,dc=example,dc=com maps to the managers role.

Note

By default, principal-to-role mapping is only applied to principals which represent groups. It is possible to configure Data Grid to also perform the mapping for user principals.

8.1.2.1. Mapping users to roles and permissions in Data Grid

Consider the following user retrieved from an LDAP server, as a collection of DNs:

CN=myapplication,OU=applications,DC=mycompany
CN=dataprocessors,OU=groups,DC=mycompany
CN=finance,OU=groups,DC=mycompany

Using the Common name role mapper, the user would be mapped to the following roles:

dataprocessors
finance

Data Grid has the following role definitions:

dataprocessors: ALL_WRITE ALL_READ
finance: LISTEN

The user would have the following permissions:

ALL_WRITE ALL_READ LISTEN

Additional resources

8.1.3. Configuring role mappers

Data Grid enables the cluster role mapper and cluster permission mapper by default. To use a different implementation for role mapping, you must configure the role mappers.

Procedure

Open your Data Grid configuration for editing.
Declare the role mapper as part of the security authorization in the Cache Manager configuration.
Save the changes to your configuration.

Role mapper configuration

XML

<cache-container>
  <security>
    <authorization>
      <common-name-role-mapper />
    </authorization>
  </security>
</cache-container>

JSON

{
  "infinispan" : {
    "cache-container" : {
      "security" : {
        "authorization" : {
          "common-name-role-mapper": {}
        }
      }
    }
  }
}

YAML

infinispan:
  cacheContainer:
    security:
      authorization:
        commonNameRoleMapper: ~

Additional resources

Data Grid configuration schema reference

8.1.4. Configuring the cluster role and permission mappers

The cluster role mapper maintains a dynamic mapping between principals and roles. The cluster permission mapper maintains a dynamic set of role definitions. In both cases, the mappings are stored in the cluster registry and can be manipulated at runtime using either the CLI or the REST API.

Prerequisites

Have ADMIN permissions for Data Grid.
Start the Data Grid CLI.
Connect to a running Data Grid cluster.

8.1.4.1. Creating new roles

Create new roles and set the permissions.

Procedure

Create roles with the user roles create command, for example:
```
user roles create --permissions=ALL_READ,ALL_WRITE simple
```

Verification

List roles that you grant to users with the user roles ls command.

user roles ls
["observer","application","admin","monitor","simple","deployer"]

Describe roles with the user roles describe command.

user roles describe simple
{
  "name" : "simple",
  "permissions" : [ "ALL_READ","ALL_WRITE" ]
}

8.1.4.2. Granting roles to users

Assign roles to users and grant them permissions to perform cache operations and interact with Data Grid resources.

Tip

Grant roles to groups instead of users if you want to assign the same role to multiple users and centrally maintain their permissions.

Prerequisites

Have ADMIN permissions for Data Grid.
Create Data Grid users.

Procedure

Create a CLI connection to Data Grid.
Assign roles to users with the user roles grant command, for example:
```
user roles grant --roles=deployer katie
```

Verification

List roles that you grant to users with the user roles ls command.

user roles ls katie
["deployer"]

8.1.4.3. Cluster role mapper name rewriters

By default, the mapping is performed using a strict string equivalence between principal names and roles. It is possible to configure the cluster role mapper to apply transformation to the principal name before performing a lookup.

Procedure

Open your Data Grid configuration for editing.
Specify a name rewriter for the cluster role mapper as part of the security authorization in the Cache Manager configuration.
Save the changes to your configuration.

Principal names may have different forms, depending on the security realm type:

Properties and Token realms may return simple strings
Trust and LDAP realms may return X.500-style distinguished names
Kerberos realms may return user@domain-style names

Names can be normalized to a common form using one of the following transformers:

8.1.4.3.1. Case Principal Transformer

XML

<cache-container>
   <security>
      <authorization>
         <cluster-role-mapper>
            <name-rewriter>
               <case-principal-transformer uppercase="false"/>
            </name-rewriter>
         </cluster-role-mapper>
      </authorization>
   </security>
</cache-container>

JSON

{
  "cache-container": {
    "security": {
      "authorization": {
        "cluster-role-mapper": {
          "name-rewriter": {
            "case-principal-transformer": {}
          }
        }
      }
    }
  }
}

YAML

cacheContainer:
  security:
    authorization:
      clusterRoleMapper:
        nameRewriter:
          casePrincipalTransformer:
            uppercase: false

8.1.4.3.2. Regex Principal Transformer

XML

<cache-container>
   <security>
      <authorization>
         <cluster-role-mapper>
            <name-rewriter>
               <regex-principal-transformer pattern="cn=([^,]+),.*" replacement="$1"/>
            </name-rewriter>
         </cluster-role-mapper>
      </authorization>
   </security>
</cache-container>

JSON

{
  "cache-container": {
    "security": {
      "authorization": {
        "cluster-role-mapper": {
          "name-rewriter": {
            "regex-principal-transformer": {
              "pattern": "cn=([^,]+),.*",
              "replacement": "$1"
            }
          }
        }
      }
    }
  }
}

YAML

cacheContainer:
  security:
    authorization:
      clusterRoleMapper:
        nameRewriter:
          regexPrincipalTransformer:
            pattern: "cn=([^,]+),.*"
            replacement: "$1"

Additional resources

Data Grid configuration schema reference

8.2. Configuring caches with security authorization

Add security authorization to caches to enforce role-based access control (RBAC). This requires Data Grid users to have a role with a sufficient level of permission to perform cache operations.

Prerequisites

Create Data Grid users and either grant them with roles or assign them to groups.

Procedure

Open your Data Grid configuration for editing.
Add a security section to the configuration.
Specify roles that users must have to perform cache operations with the authorization element.
You can implicitly add all roles defined in the Cache Manager or explicitly define a subset of roles.
Save the changes to your configuration.

Implicit role configuration

The following configuration implicitly adds every role defined in the Cache Manager:

XML

<distributed-cache>
  <security>
    <authorization/>
  </security>
</distributed-cache>

JSON

{
  "distributed-cache": {
    "security": {
      "authorization": {
        "enabled": true
      }
    }
  }
}

YAML

distributedCache:
  security:
    authorization:
      enabled: true

Explicit role configuration

The following configuration explicitly adds a subset of roles defined in the Cache Manager. In this case Data Grid denies cache operations for any users that do not have one of the configured roles.

XML

<distributed-cache>
  <security>
    <authorization roles="admin supervisor"/>
  </security>
</distributed-cache>

JSON

{
  "distributed-cache": {
    "security": {
      "authorization": {
        "enabled": true,
        "roles": ["admin","supervisor"]
      }
    }
  }
}

YAML

distributedCache:
  security:
    authorization:
      enabled: true
      roles: ["admin","supervisor"]

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 8. Security authorization with role-based access control

8.1. Data Grid user roles and permissions

8.1.1. Permissions

8.1.2. Role and permission mappers

8.1.2.1. Mapping users to roles and permissions in Data Grid

8.1.3. Configuring role mappers

Role mapper configuration

8.1.4. Configuring the cluster role and permission mappers

8.1.4.1. Creating new roles

8.1.4.2. Granting roles to users

8.1.4.3. Cluster role mapper name rewriters

8.1.4.3.1. Case Principal Transformer

8.1.4.3.2. Regex Principal Transformer

8.2. Configuring caches with security authorization

Implicit role configuration

Explicit role configuration

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links