Binding a role to an authentication scheme

Prevent unintentional role assignment when a group name or user name is found in multiple schemes.

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.

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; 

dse.yaml

The location of the dse.yaml file depends on the type of installation:
Package installations /etc/dse/dse.yaml
Tarball installations installation_location/resources/dse/conf/dse.yaml

Prerequisites

Set authorization_options.scheme_permissions: true in dse.yaml. Once enabled, roles must be associated with an authentication scheme in order to be assigned.
Warning: 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.

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;