Functionality of the eIAM roles

Once a user has been successfully authenticated, the user's roles from the eIAM-AM (Access Management) are added to the application as attributes of the authentication tokens within eIAM.

The only exception here is the "AuthOnly" onboarding pattern, as the application does not use the eIAM-AM in this case.

The eIAM service offers a 2-stage role concept for access management. The roles are administered in the eIAM-AM.

A distinction is made between access roles and application roles.

Examples of roles and in an authentication token to the application are described for the respective protocol (SAML or OIDC) under eIAM Services 1 - Federation of identities.

Access roles

These roles control whether a user is generally authorized to access the application. There are two possible roles for each application: The "Allow role" (.ALLOW) and the "Deny role" (.DENY).

Use case STS
If the required access roles are missing, eIAM calls the eIAM-AccessRequest feature, with which the user can request the missing authorization. The request can be made via a form (interactive) or the Allow role can be assigned automatically by eIAM (silent mode). Various onboarding methods are outlined under "Further use cases" below. Further information on these methods can be found under eIAM Services 5 - Onboarding.

IMPORTANT: The role check for access to application resources (authorization) is not performed by eIAM. A role check is only carried out as part of the access request. If a role exists, regardless of whether Allow or Deny, access to the application is not blocked by eIAM.

Use Case RP-PEP (eIAM-Web PEP)
One reason for the 2-stage role concept is that no adjustments need to be made to the RP-PEP (eIAM Web PEP) when application roles are added or deleted in eIAM-AM.

The access roles are checked and enforced by the eIAM Web PEP (RP-PEP). Basically, eIAM distinguishes between the "Allow role" (.ALLOW) and the "Deny role" (.DENY).

.ALLOW role	.DENY role	Access to the application
❌	❌	No, onboarding required
✅	❌	Yes
❌	✅	No
✅	✅	No

If the user does not have the required Allow role for access to the resource, the user's request is already blocked on the eIAM Web PEP.

The user's request for the resource is also blocked if the BVA has set the "Deny role". This is also the case if both the Allow and Deny roles are set

The absence of the required access role can be requested via the corresponding onboarding pattern (eIAM Services 5 - Onboarding).

Further use cases
As part of an integration with the eIAM Services 6 - Delegated Management pattern, a two-tier role concept is not absolutely necessary as long as the application takes over the authorization based on the fine-grained roles sent in the token.

If no eIAM access management is required, this is referred to as an AuthOnly pattern. In this case, no eIAM roles are supplied in the token in addition to the identity.

Naming convention for coarse-grained roles in eIAM
The naming convention for coarse-grained roles in eIAM is standardized and consists of the application name as it is managed in eIAM-AM and the qualifier for the role. A dot " . " is used as a separator.

Rough granular Allow role:
<application name from eIAM-AM>.ALLOW

Coarse granular Deny role:
<application name from eIAM-AM>.DENY

Application roles

Fine granular roles of a user are used to control access to web masks and data of an application. A user can have one or more fine-grained roles for an application.

Naming conventions for fine-grained roles in the eIAM
The naming for fine-grained roles in eIAM is standardized and consists of the application name as it is managed in eIAM-AM and the qualifier for the role. A dot " . " is used as a separator.