User credential entitlements

We can insert additional entitlements data as attribute name-value pairs into the client credential by an ISAM authorization client. Insertion can occur during the user authentication process or at any time during the process of the transaction.

For example, Security Verify Access can be configured to gather entitlements at the time that a user is authenticated. We can configure entitlement services to run during credential acquisition, collect entitlements data, and then append the data to the credential.

ISAM provides a credential attributes entitlement service that retrieves entitlements data from the user registry. Or, we can define our own entitlement services. See Authorization C API Developer Reference.

Any attribute added to the user credential can be used as ADI in a rule definition. There are also attributes that are built into the ISAM user credential when it is created by the authorization engine. Just like attributes that can be added to the credential by the resource manager, the built-in credential attributes can be used in authorization rules. The built-in credential attributes include items of information, such as the user name (or the principal UUID). The attributes also include the groups (or the group UUID) of which the user is a member.

See the Authorization C API Developer Reference for a table of valid credential attribute names. All credential attribute names begin with azn_cred_ (for example, azn_cred_principal_uuid). This table lists attribute names available in the ISAM authenticated user credential, their value, and a description.

Many attributes in this table are also available in an unauthenticated user credential, except attributes related to the identity of a user. For example, attributes such as the user name, principal UUID, group name, and group UUID, and the LDAP DN for LDAP configurations are not available in an unauthenticated credential.

When developing rules using these particular attributes, the authorization engine requires all ADI to be present before a rule can be evaluated. If the ADI is not available, the authorization decision is returned with an error status. Requiring the user to authenticate before accessing the protected object with such a rule attached ensures the authenticated credential information is available. This requirement can be achieved with an ACL entry on the object that requires authenticated access.

Parent topic: Sources for retrieving ADI