Role Enablement Authorities

This section describes role enablement authorities (REA) in DirX Access. REAs are distinguished entities in the authorization subsystem that are concerned with the resolution of role assignments. The standards relevant for this topic include:

  • XACML RBAC profile5.

  • NIST RBAC.

Use Cases

The REA use cases are as follows:

  • Entitling individual users, groups and organizational units to perform actions in DirX Access without requiring custom contents in the LDAP entries of the individual user, groups or organizational unit nodes (in the user directory tree).

  • Dynamically determining whether and which roles are assigned to a subject.

  • Determining role assignments based on multiple factors (for example, organizational affiliation AND hierarchical position).

  • With respect to persisted, static information in user repositories that may be used in determining role assignments: supporting the lookup of such information from:

    • Arbitrary LDAP attributes; for example, MyRoleAssignmentAttribute.

    • Foreign value sets; for example, MyMasterOfAnythingRoleValue; that is, role values that are not known during development time.

  • With respect to transient, potentially dynamic information in SAML assertions that may be used in determining role assignments: support the lookup of such information from:

    • Arbitrary SAML attributes; for example, MyRoleAssignmentAttribute.

    • Foreign value sets; for example, MyMasterOfAnythingRoleValue; that is, role values that are not known during development time.

Architectural Overview

The concept of an REA in the XACML RBAC profile is fundamental with respect to the support of multidimensional, dynamic role assignments. REAs use XACML policies to determine whether a subject is allowed to have a particular role assigned: the REA itself operates a role assignment policy:

  • The REA as a component is specified as follows: “_an entity that assigns role attributes and values to users or enables role attributes and values during a user’s session_.”

  • The role assignment policy is specified as follows: “_defines which roles can be enabled or assigned to which subjects. It may also specify restrictions on combinations of roles or total number of roles assigned to or enabled for a given subject. This type of policy is used by a role enablement authority_.”

For the overall authorization decision-making process, the concept of an REA implies that one XACML PDP (which is supposed to render an authorization decision may request a subject access-requested resource according to a named action) calls another XACML PDP (which is supposed to render the authorization decision may request a subject act in a dedicated role). This implies that authorization decision-making according the XACML RBAC profile is based on a PDP-tuple (operational PDP, role assignment PDP) where:

  • The operational PDP is being invoked by the PEP.

  • The role assignment PDP is being invoked by the operational PDP.

So the PDP that is supposed to render an authorization decision for RBAC (called the operational PDP above) offloads the authorization decision-making in the subject dimension (and only this dimension) to another PDP (called the role assignment PDP above).

Since REAs in DirX Access present XACML PDPs that operate on the basis of XACML policies, various degrees of freedom can be used to dynamically decide about role assignments, taking various factors into account, including:

  • Arbitrary attribute from User Repository.

  • Arbitrary attribute value(s) from User Repository.

  • Multiple attributes and values from User Repository.

  • Arbitrary user attribute from online authority (also called claims-based IdM).

  • Arbitrary user attribute value(s) from online authority (also known as claims-based IdM).

  • Multiple user attributes and values from online authority (also called claims-based IdM).

  • Environmental properties such as time and locality.

  • Combinations of the above.

REA Enablement

This section describes REA enabling in DirX Access. To enable REA:

  • An appropriate XACML policy needs to be created. This is a solution-specific task that can be performed with DirX Access Manager and/or any XML or XACML editor.

  • The REA policy returns assigned roles in the form xacml:Obligations. The contract between the operational PDP and role-enablement PDP need to specify the following items:

    • The REA PDP identifier.

    • The REA request construction identifier.

    • The AttributeId of the attribute to be read from XACML obligations.

    • The DataType of the attribute to be read from XACML obligations.
      All of these properties are configured in one XACML attribute value construction template of the operational PDP. This is the role value template and has the implementation class com.siemens.dxa.services.authz.impl.xacml.pdp.finder.attribute.subject.builder.pdp.XacmlAttributeValueBuilderPdp.

  • This XACML policy needs to be imported into the Policy Repository LDAP subtree whose name matches the target role enablement PDP (e.g., *ou=RBAC Administration‑REA,ou=ABAC,ou=Policy,ou=DirX Access,o=*MyName). This task can be performed with the DirX Access Manager or the DirX Access Console.

  • Subject to the details in the XACML policy, eventually-required configuration objects (XACML policy interpretation templates and XACML attribute value templates) need to be created. This task can be performed with DirX Access Manager (assuming that the to-be-mounted policy is not yet active, as setting it to active without supplying the dependent objects will prohibit login to DirX Access Manager).