이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 4. Securing Access to Data Grid Servers
Configure authentication and encryption mechanisms to secure access to Data Grid servers and protect your data.
4.1. Defining Data Grid Server Security Realms
Security realms provide identity, encryption, authentication, and authorization information to Data Grid server endpoints.
4.1.1. Property Realms
Property realms use property files to define users and groups.
users.properties
maps usernames to passwords in plain-text format. Passwords can also be pre-digested if you use the DIGEST-MD5
SASL mechanism or Digest
HTTP mechanism.
myuser=a_password user2=another_password
groups.properties
maps users to roles.
myuser=supervisor,reader,writer user2=supervisor
Property realm configuration
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0"> <security-realms> <security-realm name="default"> <properties-realm groups-attribute="Roles"> 1 <user-properties path="users.properties" 2 relative-to="infinispan.server.config.path" 3 plain-text="true"/> 4 <group-properties path="groups.properties" 5 relative-to="infinispan.server.config.path"/> </properties-realm> </security-realm> </security-realms> </security>
Supported authentication mechanisms
Property realms support the following authentication mechanisms:
-
SASL:
PLAIN
,DIGEST-*
, andSCRAM-*
-
HTTP (REST):
Basic
andDigest
4.1.1.1. Creating and Modifying Users
Data Grid Server requires users to authenticate against a default property realm. Before you can access Data Grid Server, you must add credentials by creating at least one user and a password. You can also add and modify the security authorization groups to which users belong.
Procedure
-
Open a terminal in
$RHDG_HOME
. -
Create and modify Data Grid users with the
user
command.
Run help user
for more details about using the command.
Creating users and passwords
Linux
$ bin/cli.sh user create myuser -p "qwer1234!"
Microsoft Windows
$ bin\cli.bat user create myuser -p "qwer1234!"
Creating users with group membership
Linux
$ bin/cli.sh user create myuser -p "qwer1234!" -g supervisor,reader,writer
Microsoft Windows
$ bin\cli.bat user create myuser -p "qwer1234!" -g supervisor,reader,writer
4.1.2. LDAP Realms
LDAP realms connect to LDAP servers, such as OpenLDAP, Red Hat Directory Server, Apache Directory Server, or Microsoft Active Directory, to authenticate users and obtain membership information.
LDAP servers can have different entry layouts, depending on the type of server and deployment. For this reason, LDAP realm configuration is complex. It is beyond the scope of this document to provide examples for all possibile configurations.
LDAP realm configuration
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0"> <security-realms> <security-realm name="default"> <ldap-realm name="ldap" 1 url="ldap://my-ldap-server:10389" 2 principal="uid=admin,ou=People,dc=infinispan,dc=org" 3 credential="strongPassword" connection-timeout="3000" read-timeout="30000" 4 connection-pooling="true" referral-mode="ignore" page-size="30" direct-verification="true"> 5 <identity-mapping rdn-identifier="uid" 6 search-dn="ou=People,dc=infinispan,dc=org"> 7 <attribute-mapping> 8 <attribute from="cn" to="Roles" filter="(&(objectClass=groupOfNames)(member={1}))" filter-dn="ou=Roles,dc=infinispan,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm> </security-realm> </security-realms> </security>
- 1
- Names the LDAP realm.
- 2
- Specifies the LDAP server connection URL.
- 3
- Specifies a principal and credentials to connect to the LDAP server.Important
The principal for LDAP connections must have necessary privileges to perform LDAP queries and access specific attributes.
- 4
- Optionally tunes LDAP server connections by specifying connection timeouts and so on.
- 5
- Verifies user credentials. Data Grid attempts to connect to the LDAP server using the configured credentials. Alternatively, you can use the
user-password-mapper
element that specifies a password. - 6
- Maps LDAP entries to identities. The
rdn-identifier
specifies an LDAP attribute that finds the user entry based on a provided identifier, which is typically a username; for example, theuid
orsAMAccountName
attribute. - 7
- Defines a starting context that limits searches to the LDAP subtree that contains the user entries.
- 8
- Retrieves all the groups of which the user is a member. There are typically two ways in which membership information is stored:
-
Under group entries that usually have class
groupOfNames
in themember
attribute. In this case, you can use an attribute filter as in the preceding example configuration. This filter searches for entries that match the supplied filter, which locates groups with amember
attribute equal to the user’s DN. The filter then extracts the group entry’s CN as specified byfrom
, and adds it to the user’sRoles
. In the user entry in the
memberOf
attribute. In this case you should use an attribute reference such as the following:<attribute-reference reference="memberOf" from="cn" to="Roles" />
This reference gets all
memberOf
attributes from the user’s entry, extracts the CN as specified byfrom
, and adds them to the user’sRoles
.
-
Under group entries that usually have class
Supported authentication mechanisms
LDAP realms support the following authentication mechanisms directly:
-
SASL:
PLAIN
,DIGEST-*
, andSCRAM-*
-
HTTP (REST):
Basic
andDigest
4.1.2.1. LDAP Realm Principal Rewriting
Some SASL authentication mechanisms, such as GSSAPI
, GS2-KRB5
and Negotiate
, supply a username that needs to be cleaned up before you can use it to search LDAP servers.
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd"
xmlns="urn:infinispan:server:11.0">
<security-realms>
<security-realm name="default">
<ldap-realm name="ldap"
url="ldap://${org.infinispan.test.host.address}:10389"
principal="uid=admin,ou=People,dc=infinispan,dc=org"
credential="strongPassword">
<name-rewriter> 1
<regex-principal-transformer name="domain-remover"
pattern="(.*)@INFINISPAN\.ORG"
replacement="$1"/>
</name-rewriter>
<identity-mapping rdn-identifier="uid"
search-dn="ou=People,dc=infinispan,dc=org">
<attribute-mapping>
<attribute from="cn" to="Roles"
filter="(&(objectClass=groupOfNames)(member={1}))"
filter-dn="ou=Roles,dc=infinispan,dc=org" />
</attribute-mapping>
<user-password-mapper from="userPassword" />
</identity-mapping>
</ldap-realm>
</security-realm>
</security-realms>
</security>
- 1
- Defines a rewriter that extracts the username from the principal using a regular expression.
4.1.3. Trust Store Realms
Trust store realms use keystores that contain the public certificates of all clients that are allowed to connect to Data Grid server.
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0"> <security-realms> <security-realm name="default"> <server-identities> <ssl> <keystore path="server.p12" 1 relative-to="infinispan.server.config.path" 2 keystore-password="secret" 3 alias="server"/> 4 </ssl> </server-identities> <truststore-realm path="trust.p12" 5 relative-to="infinispan.server.config.path" keystore-password="secret"/> </security-realm> </security-realms> </security>
Supported authentication mechanisms
Trust store realms work with client-certificate authentication mechanisms:
-
SASL:
EXTERNAL
-
HTTP (REST):
CLIENT_CERT
4.1.4. Token Realms
Token realms use external services to validate tokens and require providers that are compatible with RFC-7662 (OAuth2 Token Introspection), such as Red Hat SSO.
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0"> <security-realms> <security-realm name="default"> <token-realm name="token" auth-server-url="https://oauth-server/auth/"> 1 <oauth2-introspection introspection-url="https://oauth-server/auth/realms/infinispan/protocol/openid-connect/token/introspect" 2 client-id="infinispan-server" 3 client-secret="1fdca4ec-c416-47e0-867a-3d471af7050f"/> 4 </token-realm> </security-realm> </security-realms> </security>
Supported authentication mechanisms
Token realms support the following authentication mechanisms:
-
SASL:
OAUTHBEARER
-
HTTP (REST):
Bearer
4.2. Creating Data Grid Server Identities
Server identities are defined within security realms and enable Data Grid servers to prove their identity to clients.
4.2.1. Setting Up SSL Identities
SSL identities use keystores that contain either a certificate or chain of certificates.
If security realms contain SSL identities, Data Grid servers automatically enable encryption for the endpoints that use those security realms.
Procedure
Create a keystore for Data Grid server.
ImportantData Grid server supports the following keystore formats: JKS, JCEKS, PKCS12, BKS, BCFKS and UBER.
In production environments, server certificates should be signed by a trusted Certificate Authority, either Root or Intermediate CA.
-
Add the keystore to the
$ISPN_HOME/server/conf
directory. -
Add a
server-identities
definition to the Data Grid server security realm. - Specify the name of the keystore along with the password and alias.
4.2.1.1. SSL Identity Configuration
The following example configures an SSL identity for Data Grid server:
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0"> <security-realms> <security-realm name="default"> <server-identities> 1 <ssl> 2 <keystore path="server.p12" 3 relative-to="infinispan.server.config.path" 4 keystore-password="secret" 5 alias="server"/> 6 </ssl> </server-identities> </security-realm> </security-realms> </security>
- 1
- Defines identities for Data Grid server.
- 2
- Configures an SSL identity for Data Grid server.
- 3
- Names a keystore that contains Data Grid server SSL certificates.
- 4
- Specifies that the keystore is relative to the
server/conf
directory in$ISPN_HOME
. - 5
- Specifies a keystore password.
- 6
- Specifies a keystore alias.
4.2.1.2. Automatically Generating Keystores
Configure Data Grid servers to automatically generate keystores at startup.
Automatically generated keystores:
- Should not be used in production environments.
- Are generated whenever necessary; for example, while obtaining the first connection from a client.
- Contain certificates that you can use directly in Hot Rod clients.
Procedure
-
Include the
generate-self-signed-certificate-host
attribute for thekeystore
element in the server configuration. - Specify a hostname for the server certificate as the value.
SSL server identity with a generated keystore
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd"
xmlns="urn:infinispan:server:11.0">
<security-realms>
<security-realm name="default">
<server-identities>
<ssl>
<keystore path="server.p12"
relative-to="infinispan.server.config.path"
keystore-password="secret"
alias="server"
generate-self-signed-certificate-host="localhost"/> 1
</ssl>
</server-identities>
</security-realm>
</security-realms>
</security>
- 1
- generates a keystore using
localhost
4.2.1.3. Tuning SSL Protocols and Cipher Suites
You can configure the SSL engine, via the Data Grid server SSL identity, to use specific protocols and ciphers.
You must ensure that you set the correct ciphers for the protocol features you want to use; for example HTTP/2 ALPN.
Procedure
-
Add the
engine
element to your Data Grid server SSL identity. -
Configure the SSL engine with the
enabled-protocols
andenabled-ciphersuites
attributes.
SSL engine configuration
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0"> <security-realms> <security-realm name="default"> <server-identities> <ssl> <keystore path="server.p12" relative-to="infinispan.server.config.path" keystore-password="secret" alias="server"/> <engine enabled-protocols="TLSv1.2 TLSv1.1" 1 enabled-ciphersuites="SSL_RSA_WITH_AES_128_GCM_SHA256 2 SSL_RSA_WITH_AES_128_CBC_SHA256"/> </ssl> </server-identities> </security-realm> </security-realms> </security>
4.2.2. Setting Up Kerberos Identities
Kerberos identities use keytab files that contain service principal names and encrypted keys, derived from Kerberos passwords.
keytab files can contain both user and service account principals. However, Data Grid servers use service account principals only. As a result, Data Grid servers can provide identity to clients and allow clients to authenticate with Kerberos servers.
In most cases, you create unique principals for the Hot Rod and REST connectors. For example, you have a "datagrid" server in the "INFINISPAN.ORG" domain. In this case you should create the following service principals:
-
hotrod/datagrid@INFINISPAN.ORG
identifies the Hot Rod service. -
HTTP/datagrid@INFINISPAN.ORG
identifies the REST service.
Procedure
Create keytab files for the Hot Rod and REST services.
- Linux
$ ktutil ktutil: addent -password -p datagrid@INFINISPAN.ORG -k 1 -e aes256-cts Password for datagrid@INFINISPAN.ORG: [enter your password] ktutil: wkt http.keytab ktutil: quit
- Microsoft Windows
$ ktpass -princ HTTP/datagrid@INFINISPAN.ORG -pass * -mapuser INFINISPAN\USER_NAME $ ktab -k http.keytab -a HTTP/datagrid@INFINISPAN.ORG
-
Copy the keytab files to the
$ISPN_HOME/server/conf
directory. -
Add a
server-identities
definition to the Data Grid server security realm. - Specify the location of keytab files that provide service principals to Hot Rod and REST connectors.
- Name the Kerberos service principals.
4.2.2.1. Kerberos Identity Configuration
The following example configures Kerberos identities for Data Grid server:
<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0"> <security-realms> <security-realm name="default"> <server-identities> 1 <kerberos keytab-path="hotrod.keytab" 2 principal="hotrod/datagrid@INFINISPAN.ORG" 3 required="true"/> 4 <kerberos keytab-path="http.keytab" 5 principal="HTTP/localhost@INFINISPAN.ORG" 6 required="true"/> </server-identities> </security-realm> </security-realms> </security>
- 1
- Defines identities for Data Grid server.
- 2
- Specifies a keytab file that provides a Kerberos identity for the Hot Rod connector.
- 3
- Names the Kerberos service principal for the Hot Rod connector.
- 4
- Specifies that the keytab file must exist when Data Grid server starts.
- 5
- Specifies a keytab file that provides a Kerberos identity for the REST connector.
- 6
- Names the Kerberos service principal for the REST connector.
4.3. Configuring Endpoint Authentication Mechanisms
Configure Hot Rod and REST connectors with SASL or HTTP authentication mechanisms to authenticate with clients.
Data Grid servers require user authentication to access the command line interface (CLI) and console as well as the Hot Rod and REST endpoints. Data Grid servers also automatically configure authentication mechanisms based on the security realms that you define.
4.3.1. Data Grid Server Authentication
Data Grid servers automatically configure authentication mechanisms based on the security realm that you assign to endpoints.
SASL Authentication Mechanisms
The following SASL authentication mechanisms apply to Hot Rod endpoints:
Security Realm | SASL Authentication Mechanism |
---|---|
Property Realms and LDAP Realms | SCRAM-*, DIGEST-*, CRAM-MD5 |
Token Realms | OAUTHBEARER |
Trust Realms | EXTERNAL |
Kerberos Identities | GSSAPI, GS2-KRB5 |
SSL/TLS Identities | PLAIN |
HTTP Authentication Mechanisms
The following HTTP authentication mechanisms apply to REST endpoints:
Security Realm | HTTP Authentication Mechanism |
---|---|
Property Realms and LDAP Realms | DIGEST |
Token Realms | BEARER_TOKEN |
Trust Realms | CLIENT_CERT |
Kerberos Identities | SPNEGO |
SSL/TLS Identities | BASIC |
Default Configuration
Data Grid servers provide a security realm named "default" that uses a property realm with plain text credentials defined in $RHDG_HOME/server/ conf/users.properties
, as shown in the following snippet:
<security-realm name="default"> <properties-realm groups-attribute="Roles"> <user-properties path="users.properties" relative-to="infinispan.server.config.path" plain-text="true"/> <group-properties path="groups.properties" relative-to="infinispan.server.config.path" /> </properties-realm> </security-realm>
The endpoints
configuration assigns the "default" security realm to the Hot Rod and REST connectors, as follows:
<endpoints socket-binding="default" security-realm="default"> <hotrod-connector name="hotrod"/> <rest-connector name="rest"/> </endpoints>
As a result of the preceding configuration, Data Grid servers require authentication with a mechanism that the property realm supports.
4.3.2. Manually Configuring Hot Rod Authentication
Explicitly configure Hot Rod connector authentication to override the default SASL authentication mechanisms that Data Grid servers use for security realms.
Procedure
-
Add an
authentication
definition to the Hot Rod connector configuration. - Specify which Data Grid security realm the Hot Rod connector uses for authentication.
- Specify the SASL authentication mechanisms for the Hot Rod endpoint to use.
- Configure SASL authentication properties as appropriate.
4.3.2.1. Hot Rod Authentication Configuration
Hot Rod connector with SCRAM, DIGEST, and PLAIN authentication
<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0" socket-binding="default" security-realm="default"> 1 <hotrod-connector name="hotrod"> <authentication> <sasl mechanisms="SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 2 SCRAM-SHA-1 DIGEST-SHA-512 DIGEST-SHA-384 DIGEST-SHA-256 DIGEST-SHA DIGEST-MD5 PLAIN" server-name="infinispan" 3 qop="auth"/> 4 </authentication> </hotrod-connector> </endpoints>
Hot Rod connector with Kerberos authentication
<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0" socket-binding="default" security-realm="default"> <hotrod-connector name="hotrod"> <authentication> <sasl mechanisms="GSSAPI GS2-KRB5" 1 server-name="datagrid" 2 server-principal="hotrod/datagrid@INFINISPAN.ORG"/> 3 </authentication> </hotrod-connector> </endpoints>
4.3.2.2. Hot Rod Endpoint Authentication Mechanisms
Data Grid supports the following SASL authentications mechanisms with the Hot Rod connector:
Authentication mechanism | Description | Related details |
---|---|---|
|
Uses credentials in plain-text format. You should use |
Similar to the |
|
Uses hashing algorithms and nonce values. Hot Rod connectors support |
Similar to the |
|
Uses salt values in addition to hashing algorithms and nonce values. Hot Rod connectors support |
Similar to the |
|
Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding |
Similar to the |
|
Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding |
Similar to the |
| Uses client certificates. |
Similar to the |
|
Uses OAuth tokens and requires a |
Similar to the |
4.3.2.3. SASL Quality of Protection (QoP)
If SASL mechanisms support integrity and privacy protection settings, you can add them to your Hot Rod connector configuration with the qop
attribute.
QoP setting | Description |
---|---|
| Authentication only. |
| Authentication with integrity protection. |
| Authentication with integrity and privacy protection. |
4.3.2.4. SASL Policies
SASL policies let you control which authentication mechanisms Hot Rod connectors can use.
Policy | Description | Default value |
---|---|---|
| Use only SASL mechanisms that support forward secrecy between sessions. This means that breaking into one session does not automatically provide information for breaking into future sessions. | false |
| Use only SASL mechanisms that require client credentials. | false |
| Do not use SASL mechanisms that are susceptible to simple plain passive attacks. | false |
| Do not use SASL mechanisms that are susceptible to active, non-dictionary, attacks. | false |
| Do not use SASL mechanisms that are susceptible to passive dictionary attacks. | false |
| Do not use SASL mechanisms that accept anonymous logins. | true |
Data Grid cache authorization restricts access to caches based on roles and permissions. If you configure cache authorization, you can then set <no-anonymous value=false />
to allow anonymous login and delegate access logic to cache authorization.
Hot Rod connector with SASL policy configuration
<hotrod-connector socket-binding="hotrod" cache-container="default"> <authentication security-realm="ApplicationRealm"> <sasl server-name="myhotrodserver" mechanisms="PLAIN DIGEST-MD5 GSSAPI EXTERNAL" 1 qop="auth"> <policy> 2 <no-active value="true" /> <no-anonymous value="true" /> <no-plain-text value="true" /> </policy> </sasl> </authentication> </hotrod-connector>
As a result of the preceding configuration, the Hot Rod connector uses the GSSAPI
mechanism because it is the only mechanism that complies with all policies.
4.3.3. Manually Configuring REST Authentication
Explicitly configure REST connector authentication to override the default HTTP authentication mechanisms that Data Grid servers use for security realms.
Procedure
-
Add an
authentication
definition to the REST connector configuration. - Specify which Data Grid security realm the REST connector uses for authentication.
- Specify the authentication mechanisms for the REST endpoint to use.
4.3.3.1. REST Authentication Configuration
REST connector with BASIC and DIGEST authentication
<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0" socket-binding="default" security-realm="default"> 1 <rest-connector name="rest"> <authentication mechanisms="DIGEST BASIC"/> 2 </rest-connector> </endpoints>
REST connector with Kerberos authentication
<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:server:11.0 https://infinispan.org/schemas/infinispan-server-11.0.xsd" xmlns="urn:infinispan:server:11.0" socket-binding="default" security-realm="default"> <rest-connector name="rest"> <authentication mechanisms="SPNEGO" 1 server-principal="HTTP/localhost@INFINISPAN.ORG"/> 2 </rest-connector> </endpoints>
4.3.3.2. REST Endpoint Authentication Mechanisms
Data Grid supports the following authentications mechanisms with the REST connector:
Authentication mechanism | Description | Related details |
---|---|---|
|
Uses credentials in plain-text format. You should use |
Corresponds to the |
|
Uses hashing algorithms and nonce values. REST connectors support |
Corresponds to the |
|
Uses Kerberos tickets and requires a Kerberos Domain Controller. You must add a corresponding |
Corresponds to the |
|
Uses OAuth tokens and requires a |
Corresponds to the |
| Uses client certificates. |
Similar to the |
4.4. Disabling Data Grid Server Authentication
In local development environments or on isolated networks you can configure Data Grid servers to allow unauthenticated client requests.
Procedure
-
Remove any
security-realm
attributes from theendpoints
configuration. -
Ensure that the Hot Rod and REST connectors do not include any
authentication
definitions.
For example, the following configuration allows unauthenticated access to Data Grid:
<endpoints socket-binding="default"> <hotrod-connector name="hotrod"/> <rest-connector name="rest"/> </endpoints>
4.5. Configuring Data Grid Authorization
Authorization restricts the ability to perform operations with Data Grid and access data. You assign users with roles that have different permission levels.
4.5.1. Data Grid Authorization
Data Grid lets you configure authorization to secure Cache Managers and cache instances. When user applications or clients attempt to perform an operation on secured Cached Managers and caches, they must provide an identity with a role that has sufficient permissions to perform that operation.
For example, you configure authorization on a specific cache instance so that invoking Cache.get()
requires an identity to be assigned a role with read permission while Cache.put()
requires a role with write permission.
In this scenario, if a user application or client with the reader
role attempts to write an entry, Data Grid denies the request and throws a security exception. If a user application or client with the writer
role sends a write request, Data Grid validates authorization and issues a token for subsequent operations.
Identity to Role Mapping
Identities are security Principals of type java.security.Principal
. Subjects, implemented with the javax.security.auth.Subject
class, represent a group of security Principals. In other words, a Subject represents a user and all groups to which it belongs.
Data Grid uses role mappers so that security principals correspond to roles, which represent one or more permissions.
The following image illustrates how security principals map to roles:
4.5.1.1. Permissions
Permissions control access to Cache Managers and caches by restricting the actions that you can perform. Permissions can also apply to specific entities such as named caches.
Permission | Function | Description |
---|---|---|
CONFIGURATION |
| Defines new cache configurations. |
LISTEN |
| Registers listeners against a Cache Manager. |
LIFECYCLE |
| Stops the Cache Manager. |
ALL | - | Includes all Cache Manager permissions. |
Permission | Function | Description |
---|---|---|
|
| 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. |
ALL | - | Includes all cache permissions. |
ALL_READ | - | Combines the READ and BULK_READ permissions. |
ALL_WRITE | - | Combines the WRITE and BULK_WRITE permissions. |
Combining permissions
You might need to combine permissions so that they are useful. For example, to allow "supervisors" to run stream operations but restrict "standard" users to puts and gets only, you can define the following mappings:
<role name="standard" permission="READ WRITE" /> <role name="supervisors" permission="READ WRITE EXEC BULK"/>
Reference
4.5.1.2. Role Mappers
Data Grid includes a PrincipalRoleMapper
API that maps security Principals in a Subject to authorization roles. There are two role mappers available by default:
- IdentityRoleMapper
Uses the Principal name as the role name.
-
Java class:
org.infinispan.security.mappers.IdentityRoleMapper
-
Declarative configuration:
<identity-role-mapper />
-
Java class:
- CommonNameRoleMapper
Uses the Common Name (CN) as the role name if the Principal name is a Distinguished Name (DN). For example the
cn=managers,ou=people,dc=example,dc=com
DN maps to themanagers
role.-
Java class:
org.infinispan.security.mappers.CommonRoleMapper
-
Declarative configuration:
<common-name-role-mapper />
-
Java class:
You can also use custom role mappers that implement the org.infinispan.security.PrincipalRoleMapper
interface. To configure custom role mappers declaratively, use: <custom-role-mapper class="my.custom.RoleMapper" />
4.5.2. Declaratively Configuring Authorization
Configure authorization in your infinispan.xml
file.
Procedure
-
Configure the global authorization settings in the
cache-container
that specify a role mapper, and define a set of roles and permissions. Configure authorization for caches to restrict access based on user roles.
<infinispan> <cache-container default-cache="secured" name="secured"> <security> <authorization> 1 <identity-role-mapper /> 2 <role name="admin" permissions="ALL" /> 3 <role name="reader" permissions="READ" /> <role name="writer" permissions="WRITE" /> <role name="supervisor" permissions="READ WRITE EXEC"/> </authorization> </security> <local-cache name="secured"> <security> <authorization/> 4 </security> </local-cache> </cache-container> </infinispan>
If you do not want to apply all roles to a cache, explicitly define the roles that are authorized for caches as follows:
<infinispan> <cache-container default-cache="secured" name="secured"> <security> <authorization> <identity-role-mapper /> <role name="admin" permissions="ALL" /> <role name="reader" permissions="READ" /> <role name="writer" permissions="WRITE" /> <role name="supervisor" permissions="READ WRITE EXEC"/> </authorization> </security> <local-cache name="secured"> <security> <authorization roles="admin supervisor reader"/> 1 </security> </local-cache> </cache-container> </infinispan>
- 1
- Defines authorized roles for the cache. In this example, users who have the
writer
role only are not authorized for the "secured" cache. Data Grid denies any access requests from those users.
Reference