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 that 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 for overlapping group names and roles used for internal authentication exists. 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

Set authentication_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, that is all the permissions from a resource role are granted to the target role. ALL PERMISSIONS cannot be used with ALL AUTHENTICATION SCHEMES.

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