Chat now with support
Chat with Support

Identity Manager 8.0 - Application Roles Administration Guide

Analyzing Role Memberships and Employee Assignments

The report "Overview of all Assignments" is displayed for certain objects, for example, permissions, compliance rules or roles. The report finds all the roles, for example, departments, cost centers, locations, business roles and IT Shop structures in which there are employee who own the selected base object. In this case, direct as well as indirect base object assignments are included.

Example
  • If the report is created for a resource, all roles are determined in which there are employees with this resource.
  • If the report is created for a group, all roles are determined in which there are employees with this group.
  • If the report is created for a compliance rule, all roles are determined in which there are employees with this compliance rule.
  • If the report is created for a department, all roles are determined in which employees of the selected department are also members.
  • If the report is created for a business role, all roles are determined in which employees of the selected business role are also members.

To display detailed information about assignments

  • To display the report, select the base object from the navigation or the result list and select the report Overview of all assignments.
  • Use the Used by button in the report's toolbar to select the role class (department, location, business role or IT Shop structure) for which you determine if roles exist in which there are employees with the selected base object.

    All the roles of the selected role class are shown. The color coding of elements identifies the role in which there are employees with the selected base object. The meaning of the report control elements is explained in a separate legend. In the report's toolbar, click to open the legend.

  • Double-click a control to show all child roles belonging to the selected role.
  • By clicking the button in a role's control, you display all employees in the role with the base object.
  • Use the small arrow next to to start a wizard that allows you to bookmark this list of employee for tracking. This creates a new business role to which the employees are assigned.

Figure 1: Toolbar for Report "Overview of all assignments"

Table 15: Meaning of Icons in the Report Toolbar
Icon Meaning
Show the legend with the meaning of the report control elements
Saves the current report view as a graphic.
Selects the role class used to generate the report.

Displays all roles or only the affected roles.

Role Based Authentication Module

IMPORTANT: Users must be role-based to use application roles for logging in. Role-based login is provided for the Manager and the Web Portal. To use role-based login with other One Identity Manager tools, you should ensure that users determined through the authentication module, own the required permissions.

Different role-based authentication modules are available for role-based login on One Identity Manager tools. First, the employee memberships in application roles are determined during log in with role-based authentication. Assignments of permissions group to application roles are used to determine which permissions groups apply to the employee. A dynamic system user is determined from these permissions groups that will be used for the employee’s login.

Note: Authentication modules are defined in the One Identity Manager modules and are not available until the modules are installed.

Following role-based authentication modules are available:

Generic single sign-on (role based)

Login Data

The authentication module uses the Active Directory login data of user currently logged in on the workstation.

Prerequisites

The employee exists in the One Identity Manager database.

The employee is assigned at least one application role.

The user account exists in the One Identity Manager database and the employee is entered in the user account's master data.

Set as default

No

Single Sign-On

Yes

Front-end login allowed

Yes

Web Portal login allowed

Yes

Remarks

One Identity Manager searches for the user account according to the configuration and finds the employee assigned to the user account.

If an employee owns more than one identity, the configuration parameter "QER\Person\MasterIdentity\UseMasterForAuthentication" controls which employee is used for authentication.

  • If this configuration parameter is set, the employee’s main identity is used for authentication.
  • If the parameter is not set, the employee’s subidentity is used for authentication.

A dynamic system user determined from the employee's application roles. The user interface and the write permissions are loaded through this system user.

Changes to the data are assigned to the logged in employee.

Modify the following configuration parameters in the Designer to implement the authentication module.

Table 16: Configuration Parameters for the Authentication Module
Configuration parameter Meaning
QER\Person\OAuthAuthenticator This configuration parameter specifies whether authentication through single sign-on is supported.
QER\Person\GenericAuthenticator\
SearchTable

This configuration parameter contains the table in the One Identity Manager schema in which user information is stored. The table must contain a foreign key with the name UID_Person, which points to the table Person.

Example: ADSAccount

QER\Person\GenericAuthenticator\
SearchColumn

This configuration parameter contains the column from the One Identity Manager table (SearchTable), which is used to search for the user name of the current user.

Example: CN

QER\Person\GenericAuthenticator\
EnabledBy

This configuration parameter contains a pipe (|) delimited list of Boolean columns from the One Identity Manager table (SearchTable) enabled by the user account for the login.

QER\Person\GenericAuthenticator\
DisabledBy

This configuration parameter contains a pipe (|) delimited list of Boolean columns from the One Identity Manager table (SearchTable) disabled by the user account for the login.

Example: AccountDisabled

Employee (role based)

Login Data

Employee's central user account and password.

Prerequisites

The employee exists in the One Identity Manager database.

  • The central user account is entered in the employee's master data.
  • The password is entered in the employee's master data.

The employee is assigned at least one application role.

Set as default

Yes

Single Sign-On

No

Front-end login allowed

Yes

Web Portal login allowed

Yes

Remarks

If an employee owns more than one identity, the configuration parameter "QER\Person\MasterIdentity\UseMasterForAuthentication" controls which employee is used for authentication.

  • If this configuration parameter is set, the employee’s main identity is used for authentication.
  • If the parameter is not set, the employee’s subidentity is used for authentication.

A dynamic system user determined from the employee's application roles. The user interface and the write permissions are loaded through this system user.

Changes to the data are assigned to the logged in employee.

User Account (role based)

Login Data

The authentication module uses the Active Directory login data of user currently logged in on the workstation.

Prerequisites

The employee exists in the One Identity Manager database.

  • Permitted logins are entered in the employee's master data. The logins are expected in the form: domain\user.

The employee is assigned at least one application role.

Set as default

No

Single Sign-On

Yes

Front-end login allowed

Yes

Web Portal login allowed

Yes

Remarks

All employee logins saved in the One Identity Manager database are found. The employee whose login data matches that of the current user is used for logging in.

If an employee owns more than one identity, the configuration parameter "QER\Person\MasterIdentity\UseMasterForAuthentication" controls which employee is used for authentication.

  • If this configuration parameter is set, the employee’s main identity is used for authentication.
  • If the parameter is not set, the employee’s subidentity is used for authentication.

A dynamic system user determined from the employee's application roles. The user interface and the write permissions are loaded through this system user.

Data modifications are attributed to the current user account.

Active Directory user account (role based)

Login Data

The authentication module uses the Active Directory login data of user currently logged in on the workstation.

Prerequisites

The employee exists in the One Identity Manager database.

The employee is assigned at least one application role.

The Active Directory user account exists in the One Identity Manager database and the employee is entered in the user account's master data.

Set as default

Yes

Single Sign-On

Yes

Front-end login allowed

Yes

Web Portal login allowed

Yes

Remarks

The appropriate user account is found in the One Identity Manager database through the user's SID and the domain given at login. One Identity Manager determines which employee is assigned to the user account.

If an employee owns more than one identity, the configuration parameter "QER\Person\MasterIdentity\UseMasterForAuthentication" controls which employee is used for authentication.

  • If this configuration parameter is set, the employee’s main identity is used for authentication.
  • If the parameter is not set, the employee’s subidentity is used for authentication.

A dynamic system user determined from the employee's application roles. The user interface and the write permissions are loaded through this system user.

Data modifications are attributed to the current user account.

NOTE: If the option Connect automatically is set, authentication is no longer necessary for subsequent logins.
Active Directory user account (manual input/role based)

Login Data

Login name and password for registering with Active Directory. You do not have to enter the domain.

Prerequisites

The employee exists in the One Identity Manager database.

The employee is assigned at least one application role.

The Active Directory user account exists in the One Identity Manager database and the employee is entered in the user account's master data.

The domain for logging in are entered in the configuration parameter "TargetSystem\ADS\AuthenticationDomains".

Set as default

Yes

Single Sign-On

No

Front-end login allowed

Yes

Web Portal login allowed

Yes

Remarks

The user‘s identity is determined from a predefined list of permitted Active Directory domains. The corresponding user account and employee are determined in the One Identity Manager database, which the user account is assigned to.

If an employee owns more than one identity, the configuration parameter "QER\Person\MasterIdentity\UseMasterForAuthentication" controls which employee is used for authentication.

  • If this configuration parameter is set, the employee’s main identity is used for authentication.
  • If the parameter is not set, the employee’s subidentity is used for authentication.

A dynamic system user determined from the employee's application roles. The user interface and the write permissions are loaded through this system user.

Data modifications are attributed to the current user account.

LDAP user account (role based)

Login Data

Login name, identifier, distinguished name or user ID of an LDAP user account.

LDAP user account's password.

Prerequisites

The employee exists in the One Identity Manager database.

The employee is assigned at least one application role.

The LDAP user account exists in the One Identity Manager database and the employee is entered in the user account's master data.

The configuration data for dynamically determining the system user is defined in the application. Thus, an employee can, for example, be assigned a system user dynamically depending on their department membership.

Set as default

No

Single Sign-On

No

Front-end login allowed

Yes

Web Portal login allowed

Yes

Remarks

If you log in using a login name, identifier or user ID, the corresponding user account is determined in the One Identity Manager database through the container's domain. Logging in with a distinguished name is done directly. One Identity Manager determines which employee is assigned to the LDAP user account.

If an employee owns more than one identity, the configuration parameter "QER\Person\MasterIdentity\UseMasterForAuthentication" controls which employee is used for authentication.

  • If this configuration parameter is set, the employee’s main identity is used for authentication.
  • If the parameter is not set, the employee’s subidentity is used for authentication.

A dynamic system user determined from the employee's application roles. The user interface and the write permissions are loaded through this system user.

Data modifications are attributed to the current user account.

Modify the following configuration parameters in the Designer to implement the authentication module.

Table 17: Configuration Parameters for the Authentication Module
Configuration parameter Meaning

TargetSystem\LDAP\Authentication

The configuration parameter allows configuration of the LDAP authentication module.

TargetSystem\LDAP\Authentication\Authentication

The configuration parameter specified the authentication mechanism. Permitted values are "Secure", "Encryption", "SecureSocketsLayer", "ReadonlyServer", "Anonymous", "FastBind", "Signing", "Sealing", "Delegation" and "ServerBind". The value can be combined with commas (,). For more information about authentication types, see the MSDN Library.

Default is ServerBind.

TargetSystem\LDAP\Authentication\Port

LDAP server's port. Default is port 389.

TargetSystem\LDAP\Authentication\RootDN

The configuration parameter contains the root domain's distinguished name.

Syntax:

dc=MyDomain

TargetSystem\LDAP\Authentication\Server

The configuration parameter contains the name of the LDAP server.

HTTP header (role based)

The authentication module support authentication through Web Single Sign-On solutions that work with proxy-based architecture.

Login Data

Employee's central user account or personnel number.

Prerequisites

The employee exists in the One Identity Manager database.

  • The central user account or personnel number is entered in the employee's master data.

The employee is assigned at least one application role.

Set as default

Yes

Single Sign-On

Yes

Front-end login allowed

No

Web Portal login allowed

Yes

Remarks

You must pass the user (in the form: UserName =<user name of authenticated user>) in the HTTP header. The employee is found in the One Identity Manager database whose central user account or personnel number matches the user name passed down.

If an employee owns more than one identity, the configuration parameter "QER\Person\MasterIdentity\UseMasterForAuthentication" controls which employee is used for authentication.

  • If this configuration parameter is set, the employee’s main identity is used for authentication.
  • If the parameter is not set, the employee’s subidentity is used for authentication.

A dynamic system user determined from the employee's application roles. The user interface and the write permissions are loaded through this system user.

Changes to the data are assigned to the logged in employee.

OAuth 2.0/OpenID Connect (role-based)

The authorization module supports the authorization code for OAuth 2.0 and OpenID Connect. For more detailed 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 which can return an OAuth 2.0 token.

Login Data

Dependent on the authentication method of the secure token service.

Prerequisites

The employee exists in the One Identity Manager database.

The employee is assigned at least one application role.

The user account exists in the One Identity Manager database and the employee is entered in the user account's master 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 owns more than one identity, the configuration parameter "QER\Person\MasterIdentity\UseMasterForAuthentication" controls which employee is used for authentication.

  • If this configuration parameter is set, the employee’s main identity is used for authentication.
  • If the parameter is not set, the employee’s subidentity is used for authentication.

A dynamic system user determined from the employee's application roles. The user interface and the write 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.

The respective user interface prompts for the authorization code. The configuration parameter "QER\Person\OAuthAuthenticator\LoginEndpoint" is used to open an extra login dialog box for determining the authorization code. The authentication module requires an access token from the token endpoint and the certificate is required to check the security token. In the process, an attempt is made to find the certificate from the web application configuration. If this is not possible, configuration parameters are applied. To find the certificate for testing the token, the certificate stores are queries in the following order:

  1. Web application configuration (table QBMWebApplication)
    1. Certificate text (QBMWebApplication.CertificateText) .
    2. Subject or finger print from the local store (QBMWebApplication.OAuthCertificateSubject and QBMWebApplication.OAuthCertificateThumbPrint).
    3. Certificate endpoint (QBMWebApplication.CertificateEndpoint).

      In addition, the subject or finger print is used to check certificates from the server if they are given and do not exist locally on the server.

  2. Configuration Parameter
    1. Certificate text (configuration parameter "QER\Person\OAuthAuthenticator\CertificateText").
    2. Subject or finger print from the local store (configuration parameter "QER\Person\OAuthAuthenticator\CertificateSubject" and "QER\Person\OAuthAuthenticator\CertificateThumbPrint").
    3. Certificate endpoint (configuration parameter "QER\Person\OAuthAuthenticator\CertificateEndpoint").

      In addition, the subject or finger print is used to check certificates from the server if they are given and do not exist locally on the server.

    4. JSON Web Key endpoint (configuration parameter "QER\Person\OAuthAuthenticator\JsonWebKeyEndpoint").

A claim type is required to find the user account from the user information. In addition, it is specified which One Identity Manager schema information should be used to search for the user account.

Authentication through OpenID is built on OAuth. OpenID Connection authentication uses the same mechanisms, but make user claims available either in an ID token or through a UserInfo endpoint. Other configuration settings are required for using OpenID Connect. If the configuration parameter "QER\Person\OAuthAuthenticator\Scope" contains the value "openid", the authentication module uses OpenID Connect.

Modify the following configuration parameters in the Designer to implement the authentication module.

Table 18: Configuration Parameters for the Authentication Module

Configuration Parameter

Meaning

QER\Person\OAuthAuthenticator

This configuration parameter specifies whether authentication is supported through security tokens.

QER\Person\OAuthAuthenticator\
CertificateEndpoint

The configuration parameter contain the certificate endpoint's Uniform Resource Locator (URL) on the authorization server.

Example: https://localhost/RSTS/SigningCertificate

QER\Person\OAuthAuthenticator\
CertificateSubject

The configuration parameter contain the subject of the certificate to use for testing. Either subject or finger print must be set.

QER\Person\OAuthAuthenticator\
CertificateThumbPrint

This configuration parameter contains the fingerprint of the certificate used to verify the security token.

QER\Person\OAuthAuthenticator\
ClientID

This configuration parameter specifies whether the client application supports this authentication.

QER\Person\OAuthAuthenticator\
ClientID\Web

This configuration parameter contains the web application's Uniform Resource Name URN, which supports this authentication.

Example: urn:OneIdentityManager/Web

QER\Person\OAuthAuthenticator\
ClientID\Windows

This configuration parameter contains the native application's Uniform Resource Name URN, which supports this authentication.

Example: urn:OneIdentityManager/WinClient

QER\Person\OAuthAuthenticator\
DisabledByColumns

This configuration parameter contains a pipe (|) delimited list of Boolean columns from the One Identity Manager table (SearchTable) disabled by the user account for the login.

Example: AccountDisabled

QER\Person\OAuthAuthenticator\
EnabledByColumns

This configuration parameter contains a pipe (|) delimited list of Boolean columns from the One Identity Manager table (SearchTable) enabled by the user account for the login.

QER\Person\OAuthAuthenticator\
IssuerName

This configuration parameter contains the certificate issuer's Uniform Resource Name (URN) for verifying the security token.

Example: urn:STS/identity

QER\Person\OAuthAuthenticator\
LoginEndpoint

This configuration parameter contains the Uniform Resource Locator (URL) of the Secure Token Service login page.

Example: http://localhost/rsts/login

QER\Person\OAuthAuthenticator\
Resource

This configuration parameter contains the Uniform Resource Name (URN) of the resourec to be queried, for example ADFS.

QER\Person\OAuthAuthenticator\
SearchClaim

This configuration parameter contains the claim type's Uniform Resource Identifier (URI) found from the login data.

Example: name of an entity

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

QER\Person\OAuthAuthenticator\
SearchColumn

This configuration parameter contains the column from the One Identity Manager table (SearchTable), which is used to search for user data. Equivalent to the claim type (SearchClaim) in the One Identity Manager schema.

Example: ObjectGUID

QER\Person\OAuthAuthenticator\
SearchTable

This configuration parameter contains the table in the One Identity Manager schema in which user information is stored. The table must contain a foreign key with the name UID_Person, which points to the table Person.

Example: ADSAccount

QER\Person\OAuthAuthenticator\
TokenEndpoint

This configuration parameter contains the token endpoint's Uniform Resource Identifier (URL) of the authorization server for returning the access token to the client for logging in.

Example: https://localhost/rsts/oauth2/token

QER\Person\OAuthAuthenticator\
UserNameClaim

This configuration parameter contains the claim type's Uniform Resource Identifier (URL) used to label change data (XUserInserted, XUserUpdated)..

Example: User Principle Name (UPN)

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

QER\Person\OAuthAuthenticator\
InstalledRedirectUri

This configuration parameter contains the Uniform Resource Identifier (URL) for forwarding to installed applications.

Example: urn:InstalledApplication

QER\Person\OAuthAuthenticator\
AllowSelfSignedCertsForTLS

The configuration parameter specifies whether self-signed certificates are allowed for connecting to the token and UserInfo endpoint.

QER\Person\OAuthAuthenticator\
CertificateText

This configuration parameter contains the contents of the certificate as a Base64 coded string. It is used if no certificate is configured.

QER\Person\OAuthAuthenticator\
JsonWebKeyEndpoint

This configuration parameter contains the Uniform Resource Identifier (URL) of the JSON Web Key endpoint, which supplies the signature key. At the moment, only JWK files, which contain the certificate in the x5c field are supported.

QER\Person\OAuthAuthenticator\
LogoutEndpoint

This configuration parameter contains the Uniform Resource Identifier (URL) of the log off end point.

Example: http://localhost/rsts/login?wa=wsignout1.0

QER\Person\OAuthAuthenticator\
SharedSecret

This configuration parameter contains the Share-Secret value used for authenticating at the token enpoint.

Table 19: Additional Configuration Parameters for OpenID Connect

Configuration Parameter

Meaning

QER\Person\OAuthAuthenticator\
Scope

This configuration parameter specifies the authentication log. If the configuration parameter has the value "openid", OpenID Connect is used and otherwise OAuth2.

QER\Person\OAuthAuthenticator\
UserInfoEndpoint

This configuration parameter contains the Uniform Resource Locator (URL) of the OpenID Connection UserInfo endpoint.

Related Documents