Since IAM requirements differ greatly depending on the application, eIAM offers various existing integration patterns. The eIAM dossier should help to determine the optimal integration pattern for the needs of the application to be integrated. The subsequent modification of the integration pattern requires effort on the part of the application as well as on the part of eIAM.
Pattern - Integration without Access Management in eIAM (Authentication Only)
With this form of integration, only the authentication service is offered.
In this integration pattern, no upstream RP-PEP is required, as the application does not show any increased need for protection. The web browser communicates directly with the application.
In this integration pattern, the application only obtains the "authentication" service from the eIAM service.
The complete access management including the administration of authorisations is done by the application itself.
The authenticating identity (IdP) must be linked to a federated identity!
The result is a token with the following information:
Identifier of the electronic identity (persistent)
Some attributes of the accessing subject (content and quality depending on the identity)
Information on the quality of the authentication performed
Following eIAM functions can not be ordered with the Authentication Only Pattern
eIAM-AM (access management)
eIAM-LDS (LDAP directory with user information)
eIAM-Webservice (web service as interface to eIAM)
Provision of identity data from eIAM for the application
Corresponds to eIAM Performance 1 at
Pattern - Integration with Access Management in eIAM
The application access must be made via a user access request to the responsible BVA (user administrator application).
In this integration pattern, no upstream RP-PEP is required, as the application does not show an increased need for protection. The web browser communicates directly with the application.
In this integration pattern, the application continues to obtain the "authentication" service from the eIAM service.
In the eIAM-AM client of the CE, authorisations (roles) and other attributes can be managed via the subject. Access management can be carried out completely or partially in the eIAM-AM. For applications with complex authorisation logic, it is recommended to provide for this in the application.
The result is a token with the following information:--
Identifier of the electronic identity (persistent)
Some attributes of the accessing subject (content and quality depending on the identity)
Information on the quality of the authentication performed
Roles and attributes from Access Management in eIAM (eIAM-AM)
The application can obtain all attributes required from eIAM from the token via the accessing subject.
Corresponds to eIAM performance 1 and 7 at
Pattern - Integration with Access Management in eIAM (eIAM-AM) and backchannel for attributes
Application access is via an automated mail dispatch with a one-time onboarding code to the user.
In this integration pattern, no upstream RP-PEP is needed as the application does not show an increased need for protection. The web browser communicates directly with the application.
In this integration pattern, the application continues to obtain the "authentication" service from the eIAM service.
In the eIAM-AM client of the CE, authorisations (roles) and other attributes can be managed via the subject. Access management can be carried out completely or partially in the eIAM-AM. For applications with complex authorisation logic, it is recommended to provide for this in the application.
The result is a token with the following information:
Identifier of the electronic identity (persistent).
Some attributes of the accessing subject (content and quality depending on the identity).
Information on the quality of the authentication performed.
Roles and attributes from access management in eIAM (eIAM-AM).
The application cannot obtain all attributes required from eIAM from the token via the accessing subject (e.g. only the identifier).
The application must obtain additional attributes from eIAM via the accessing subject via a so-called backchannel. For this purpose eIAM offers:
A web service interface (SOAP Web Service).
A ldap interface (read-only access possible).
Corresponds to eIAM performance 1,7 and 9 at
Pattern - Integration with Access Management in eIAM and upstream RP-PEP
In this integration pattern, an upstream RP-PEP is required because the application has an increased need for protection and is therefore located in an appropriate network zone.
All communication takes place from the web browser via the RP-PEP to the application. The RP-PEP enforces that access to the application is only possible if:
the accessing subject has been successfully authenticated beforehand
the authentication was carried out with the minimum accepted quality
the accessing subject has a corresponding role in the eIAM-AM that allows this access
In this integration pattern, the application continues to obtain the service "Authentication" from the service eIAM.
In this pattern, at least one so-called coarse authorisation role must be managed in the eIAM-AM, which allows the user to access the application via the RP-PEP in the secured zone.
In the eIAM-AM client of the CE, authorisations (roles) and other attributes can be managed via the subject. Access management can be carried out completely or partially in the eIAM-AM. For applications with complex authorisation logic, it is recommended to provide for this in the application.
The result is a token with the following information:
Identifier of the electronic identity (persistent).
Some attributes of the accessing subject (content and quality depending on the identity)
Information on the quality of the authentication performed
Roles and attributes from Access Management in eIAM (eIAM-AM)
The application can obtain all the attributes required by eIAM from the token via the accessing subject.
