NOTE: This authentication module is available if the Identity Management Base Module is installed.
The authorization module supports the authorization code for OAuth 2.0 and OpenID Connect. For more information about the authorization code flow, see, for example, the OAuth Specification or the OpenID Connect Specification.
This authentication module uses a Secure Token Service for logging in. This login procedure can be used with every Secure Token Service that can return an OAuth 2.0 token.
|
Credentials |
Dependent on the authentication method of the secure token service. |
|
Prerequisites |
-
The system user with permissions exists in the database.
-
The employee exists in the database.
-
The system user is entered in the employee's main data.
-
The user account exists in the database and the employee is entered in the user account's main data. |
|
Set as default |
No |
|
Single sign-on |
No |
|
Front-end login allowed |
Yes |
|
Web Portal login allowed |
Yes |
|
Remarks |
One Identity Manager determines which employee is assigned to the user account.
If an employee has more than one identity, the QER | Person | MasterIdentity | UseMasterForAuthentication configuration parameter controls which employee identity is used for authentication.
-
If this configuration parameter is set, the employee’s main identity is used for authentication.
-
If this configuration parameter is set, the employee’s subidentity is used for authentication.
The user interface and permissions are loaded through the system user that is directly assigned to the employee found.
Data modifications are attributed to the current user account. To do this, the claim type whose value is used for labeling data changes must be declared. |
NOTE: If the authentication module cannot find a matching user for the claim value, it searches for the claim value in permitted system users' credentials (DialogUser.AuthentifierLogons). If an entry is found there, then that system user is logged in. To allocate the data changes, the values are used from the respective claims. If a matching user is found, the fallback cannot be used anymore.
Related topics
NOTE: This authentication module is available if the Identity Management Base Module is installed.
The authorization module supports the authorization code for OAuth 2.0 and OpenID Connect. For more information about the authorization code flow, see, for example, the OAuth Specification or the OpenID Connect Specification.
This authentication module uses a Secure Token Service for logging in. This login procedure can be used with every Secure Token Service that can return an OAuth 2.0 token.
|
Credentials |
Dependent on the authentication method of the secure token service. |
|
Prerequisites |
-
The employee exists in the database.
-
The employee is assigned at least one application role.
-
The user account exists in the database and the employee is entered in the user account's main data. |
|
Set as default |
No |
|
Single sign-on |
No |
|
Front-end login allowed |
Yes |
|
Web Portal login allowed |
Yes |
|
Remarks |
One Identity Manager determines which employee is assigned to the user account.
If an employee has more than one identity, the QER | Person | MasterIdentity | UseMasterForAuthentication configuration parameter controls which employee identity is used for authentication.
-
If this configuration parameter is set, the employee’s main identity is used for authentication.
-
If this configuration parameter is set, the employee’s subidentity is used for authentication.
A dynamic system user is determined from the employee's application roles. The user interface and the permissions are loaded through this system user.
Data modifications are attributed to the current user account. To do this, the claim type whose value is used for labeling data changes must be declared. |
NOTE: If the authentication module cannot find a matching user for the claim value, it searches for the claim value in permitted system users' credentials (DialogUser.AuthentifierLogons). If an entry is found there, then that system user is logged in. To allocate the data changes, the values are used from the respective claims. If a matching user is found, the fallback cannot be used anymore.
Related topics
NOTE: This authentication module is available if the Target System Synchronization Module is installed.
This authentication module integrates the default method for Synchronization Editor login.
|
Credentials |
Login uses the sa system user. |
|
Prerequisites |
|
|
Set as default |
Yes |
|
Single sign-on |
No |
|
Front-end login allowed |
No |
|
Web Portal login allowed |
No |
|
Remarks |
You must not change the system user sa. The system user is overwritten with each schema update. |
NOTE: This authentication module is available if the Configuration Module is installed.
The authentication module integrates the default method for Web Designer login, to access the database before the first user login.
|
Credentials |
Login uses the sa system user. |
|
Prerequisites |
|
|
Set as default |
Yes |
|
Single sign-on |
No |
|
Front-end login allowed |
No |
|
Web Portal login allowed |
No |
|
Remarks |
You must not change the system user sa. The system user is overwritten with each schema update. |
