Binding a Role to an Authentication Scheme

Prevent unintentional role assignment when a group name or user name is found in multiple schemes. When a role has execute permission on a scheme, the role can only be applied to users who authenticated against that scheme.

All permissions granted to roles that reflect LDAP groups to which the user belongs—directly or indirectly—are inherited. The inherited permissions include login permission, scheme permissions, proxy execution permissions, and object permissions.

Enforcing scheme permissions

Unintentional role assignments could occur when managing roles using LDAP (role_management_options.mode: ldap). DSE Role Manager assigns roles by matching the user’s groups to a role by name. Users authenticating against the internal scheme automatically get the role associated with their login and password. If the same user exists in LDAP, all matching group-role names are also assigned.

Likewise, when an LDAP user authenticates, all group-role matches get assigned. In mixed environments with both internal and LDAP authentication, the potential exists for overlapping group names and roles used for internal authentication. For example, an internal account such as admin might overlap with the LDAP group admin. DataStax recommends enabling scheme_permissions and granting execute on schemes to the corresponding roles.

Scheme permission `CQL` Syntax

Roles are associated or removed from a scheme using the CQL GRANT and REVOKE commands:

To associate role with a scheme:

GRANT EXECUTE
ON [ALL AUTHENTICATION SCHEMES|INTERNAL SCHEME|LDAP SCHEME|KERBEROS SCHEME]
TO <role_name>;

To remove a role from a scheme:

REVOKE EXECUTE
ON [ALL AUTHENTICATION SCHEMES|INTERNAL SCHEME|LDAP SCHEME|KERBEROS SCHEME]
FROM <role_name>;

Prerequisites

Locate the dse.yaml configuration file. The location of this file depends on the type of installation:
- Package installations: /etc/dse/dse.yaml
- Tarball installations: <installation_location>/resources/dse/conf/dse.yaml
Set authorization_options.scheme_permissions: true in dse.yaml. Once enabled, roles must be associated with an authentication scheme in order to be assigned.

Roles are resources that can be assigned to another role. Permissions are inherited, meaning that all the permissions from a resource role are granted to the target role.

Procedure

Allow role assignment for users authenticating with any scheme:
```
GRANT EXECUTE
ON ALL AUTHENTICATION SCHEMES
TO <role_name>;
```
Allow role assignment only for users authenticating with LDAP:
```
GRANT EXECUTE
ON LDAP SCHEME
TO <role_name>;
```
Allow role assignment only for users authenticating with internal:
```
GRANT EXECUTE
ON INTERNAL SCHEME
TO <role_name>;
```
Allow role assignment only for users authenticating with Kerberos:
```
GRANT EXECUTE
ON KERBEROS SCHEME
TO <role_name>;
```
Allowing role assignment for multiple schemes, such as users authenticating with internal or LDAP, requires executing multiple CQL statements:
```
GRANT EXECUTE ON INTERNAL SCHEME TO <role_name>;
GRANT EXECUTE on LDAP SCHEME to <role_name>;
```

Binding a Role to an Authentication Scheme

Enforcing scheme permissions

Scheme permission `CQL` Syntax

Prerequisites

Procedure

Was this helpful?

Give Feedback

Binding a Role to an Authentication Scheme

Enforcing scheme permissions

Scheme permission CQL Syntax

Prerequisites

Procedure

Was this helpful?

Scheme permission `CQL` Syntax