Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 3. Programmatically configuring user roles and permissions
Configure security authorization programmatically when using embedded caches in Java applications.
3.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 |
---|---|---|
| ALL | Superuser with all permissions including control of the Cache Manager lifecycle. |
| ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR, CREATE |
Can create and delete Data Grid resources in addition to |
| ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR |
Has read and write access to Data Grid resources in addition to |
| ALL_READ, MONITOR |
Has read access to Data Grid resources in addition to |
| MONITOR |
Can view statistics via JMX and the |
Additional resources
3.1.1. Permissions
User roles are sets of permissions with different access levels.
Permission | Function | Description |
CONFIGURATION |
| Defines new cache configurations. |
LISTEN |
| Registers listeners against a Cache Manager. |
LIFECYCLE |
| Stops the Cache Manager. |
CREATE |
| Create and remove container resources such as caches, counters, schemas, and scripts. |
MONITOR |
|
Allows access to JMX statistics and the |
ALL | - | Includes all Cache Manager permissions. |
Permission | Function | Description |
READ |
| Retrieves entries from a cache. |
WRITE |
| Writes, replaces, removes, evicts data in a cache. |
EXEC |
| Allows code execution against a cache. |
LISTEN |
| Registers listeners against a cache. |
BULK_READ |
| Executes bulk retrieve operations. |
BULK_WRITE |
| Executes bulk write operations. |
LIFECYCLE |
| Starts and stops a cache. |
ADMIN |
| Allows access to underlying components and internal structures. |
MONITOR |
|
Allows access to JMX statistics and the |
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
3.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 themanagers
role.
3.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
3.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.
With embedded caches you can programmatically configure role and permission mappers with the principalRoleMapper()
and rolePermissionMapper()
methods.
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
3.2. Enabling and configuring authorization for embedded caches
When using embedded caches, you can configure authorization with the GlobalSecurityConfigurationBuilder
and ConfigurationBuilder
classes.
Procedure
-
Construct a
GlobalConfigurationBuilder
and enable security authorization with thesecurity().authorization().enable()
method. -
Specify a role mapper with the
principalRoleMapper()
method. If required, define custom role and permission mappings with the
role()
andpermission()
methods.GlobalConfigurationBuilder global = new GlobalConfigurationBuilder(); global.security().authorization().enable() .principalRoleMapper(new ClusterRoleMapper()) .role("myroleone").permission(AuthorizationPermission.ALL_WRITE) .role("myroletwo").permission(AuthorizationPermission.ALL_READ);
Enable authorization for caches in the
ConfigurationBuilder
.Add all roles from the global configuration.
ConfigurationBuilder config = new ConfigurationBuilder(); config.security().authorization().enable();
Explicitly define roles for a cache so that Data Grid denies access for users who do not have the role.
ConfigurationBuilder config = new ConfigurationBuilder(); config.security().authorization().enable().role("myroleone");
3.3. Adding authorization roles at runtime
Dynamically map roles to permissions when using security authorization with Data Grid caches.
Prerequisites
- Configure authorization for embedded caches.
-
Have
ADMIN
permissions for Data Grid.
Procedure
-
Obtain the
RolePermissionMapper
instance. Define new roles with the
addRole()
method.MutableRolePermissionMapper mapper = (MutableRolePermissionMapper) cacheManager.getCacheManagerConfiguration().security().authorization().rolePermissionMapper(); mapper.addRole(Role.newRole("myroleone", true, AuthorizationPermission.ALL_WRITE, AuthorizationPermission.LISTEN)); mapper.addRole(Role.newRole("myroletwo", true, AuthorizationPermission.READ, AuthorizationPermission.WRITE));
Additional resources
3.4. Executing code with secure caches
When you construct a DefaultCacheManager
for an embedded cache that uses security authorization, the Cache Manager returns a SecureCache
that checks the security context before invoking any operations. A SecureCache
also ensures that applications cannot retrieve lower-level insecure objects such as DataContainer
. For this reason, you must execute code with a Data Grid user that has a role with the appropriate level of permission.
Prerequisites
- Configure authorization for embedded caches.
Procedure
If necessary, retrieve the current Subject from the Data Grid context or
AccessControlContext
:Security.getSubject();
Wrap method calls in a
PrivilegedAction
to execute them with the Subject.Security.doAs(mySubject, (PrivilegedAction<String>)() -> cache.put("key", "value"));
You can use the Security.doAs()
or Subject.doAs()
method. Data Grid recommends Security.doAs()
for better performance.
Additional resources
3.5. Configuring the access control list (ACL) cache
When you grant or deny roles to users, Data Grid stores details about which users can access your caches internally. This ACL cache improves performance for security authorization by avoiding the need for Data Grid to calculate if users have the appropriate permissions to perform read and write operations for every request.
Whenever you grant or deny roles to users, Data Grid flushes the ACL cache to ensure it applies user permissions correctly. This means that Data Grid must recalculate cache permissions for all users each time you grant or deny roles. For best performance you should not frequently or repeatedly grant and deny roles in production environments.
Procedure
- Open your Data Grid configuration for editing.
Specify the maximum number of entries for the ACL cache with the
cache-size
attribute.Entries in the ACL cache have a cardinality of
caches * users
. You should set the maximum number of entries to a value that can hold information for all your caches and users. For example, the default size of1000
is appropriate for deployments with up to 100 caches and 10 users.Set the timeout value, in milliseconds, with the
cache-timeout
attribute.If Data Grid does not access an entry in the ACL cache within the timeout period that entry is evicted. When the user subsequently attempts cache operations then Data Grid recalculates their cache permissions and adds an entry to the ACL cache.
ImportantSpecifying a value of
0
for either thecache-size
orcache-timeout
attribute disables the ACL cache. You should disable the ACL cache only if you disable authorization.- Save the changes to your configuration.
ACL cache configuration
XML
<infinispan> <cache-container name="acl-cache-configuration"> <security cache-size="1000" cache-timeout="300000"> <authorization/> </security> </cache-container> </infinispan>
JSON
{ "infinispan" : { "cache-container" : { "name" : "acl-cache-configuration", "security" : { "cache-size" : "1000", "cache-timeout" : "300000", "authorization" : {} } } } }
YAML
infinispan: cacheContainer: name: "acl-cache-configuration" security: cache-size: "1000" cache-timeout: "300000" authorization: ~
Additional resources