To verify the identity of users who log in to Identity Governance, you need an LDAP authentication server. Identity Governance supports Active Directory and eDirectory. For example, you can use the Identity Vault for Identity Manager as an authentication server. Users can log in to Identity Governance immediately after installation if the users in the specified containers of the authentication server have passwords. Without these login accounts, only the bootstrap administrator can log in immediately.
Identity Governance uses the One SSO Provider (OSP) authentication service, which supports the OAuth2 specification. With OSP, you can provide single sign-on access among Identity Governance and other applications, such as Identity Manager Home and Provisioning Dashboard. All requests to OSP use the http or https protocols.
NOTE:OSP is always the login mechanism for Identity Governance even in a non-SSO environment.
The OSP authentication service supports the OAuth2 specification and requires an LDAP authentication server. Identity Governance works with eDirectory and Microsoft Active Directory. You must create the LDAP server before you install Identity Governance.
You can configure the type of authentication that you want OSP to use: userID and password, Kerberos, or SAML 2.0. However, OSP does not support MIT-style Kerberos or SAP login tickets.
If you use the Identity Vault as your authentication service, users with the CNs and passwords in the specified container can log in to Identity Governance immediately after installation. Without these login accounts, only the administrator that you specify during installation can log in immediately.
When a user directs the browser to one of the browser-based components, the component determines that authentication is required and temporarily redirects the browser to the OSP service. The OSP service authenticates the user, either by asking the user for a name/password or, if so configured, by asking the Kerberos or SAML provider to authenticate the user. OSP then issues an OAuth2 access token and redirects the browser back to the browser-based component. The component uses the token during the user’s session to provide SSO access to any of the browser-based components.
OSP and Kerberos ensure that users only need to log in once to create a session with Identity Governance and Identity Reporting. If the user’s session times out, authorization occurs automatically and without user intervention.
Identity Governance allows you to configure the user logout experience. If the option Use Logout Landing page is set to True, the user in a Kerberos environment can logout and OSP does not reauthorize the user. The user is presented with the landing page.
If the option is set to False, after logging out, users should always close the browser to ensure that their sessions end. Otherwise, the application redirects the user to the login window and OSP reauthorizes the user session.
Using a SAML 2.0 Identity Provider (IDP) with OSP can provide SSO for multiple applications, such as applications beyond just Identity Governance and Identity Manager.
When a browser-based component requests that OSP provide an OAuth2 token to the component, OSP first contacts the SAML IDP to authenticate the user. If the user is not yet authenticated with the IDP, the IDP requires the user to enter credentials. The IDP then responds to OSP that the user is authenticated and the OAuth2 token is issued. If the user is already authenticated with the IDP, the IDP skips the request for the user’s credentials.
When the user logs out using a browser-based component, the component first informs OSP of the logout request. OSP then informs the SAML IDP of the logout request. In most cases this will result in the browser displaying the IDP's "logged out" page.
For OSP and SSO to function, you must install OSP. Then specify the URLs for client access to each component, the URL that redirects validation requests to OSP, and settings for the authentication server. You can provide this information during installation or afterward with the Identity Governance Configuration Utility, or the Roles Based Provisioning Module (RBPM) configuration utility if you integrate with Identity Manager. You can also specify the settings for your Kerberos ticket server or SAML IDP.
During installation, you create a bootstrap administrator account that can immediately log in and configure Identity Governance. This account is useful if you do not have an authentication server before installing Identity Governance, and thus do not have any specified login users. The bootstrap administrator can access all items in the administration console, except for Reviews and Access Request.
The installation process creates a text file that stores the credentials for the bootstrap administrator. The file name is adminusers.txt, and places it in the following directory:
Linux: Default location in /opt/netiq/idm/apps/idgov/osp
Windows: Default location in c:\netiq\idm\apps\idgov\osp
IMPORTANT:To ensure system security, it is important that you use this text file, rather than adding this account to your LDAP container.
The bootstrap administrator account does not link to an account for a real person. You should not continue using this account after you have Identity Governance running in a production environment. Instead, as soon as you have collected user accounts, assign one of the collected accounts as a global administrator. For more information about assigning authorizations, see Understanding Authorizations in Identity Governance.
NOTE:The name for the bootstrap administrator account must be unique. Do not duplicate the name of any accounts already in the adminusers.txt file or in the container source or subtrees that you use for authentication. Also, do not use “admin” or “administrator” for the account name.
During installation, you must provide a password that the Identity Governance service uses for authorized interactions with the authentication server. The installation process assumes that you want to use OSP with an LDAP server. By default, the installation program places the TLS/SSL trust certificates in the cacerts keystore file of the Java Runtime Environment (JRE) for the Apache Tomcat instance that hosts OSP. To use SAML 2.0 authentication, you must manually install the SAML Identity Provider’s TLS/SSL certificate in the truststore that you want to use. Also, when using a Certificate Authority (CA) to issue certificates for the LDAP server, SAML IDP, or Advanced Authentication Framework servers, you can install the CA's trusted root certificate into the truststore and remove any server-specific certificates. For more information, see Prerequisites for One SSO Provider.
To use a non-default trust store or to change the password of the default trust store, use the Identity Governance Configuration Update utility.
Linux: configupdate.sh
Windows: configupdate.bat
Then modify the keystore settings in the configuration utility. For more information, see Running the Identity Governance Configuration Utility.