To verify the identity of users who log in to Identity Governance, you need an LDAP authentication server and an authentication service. Identity Governance supports Active Directory and eDirectory as authentication servers and One SSO Provider (OSP) and Access Manager as authentication services. 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 allows the following authentication service configurations to achieve single sign-on in your environment:
OSP
Access Manager
Access Manager connecting to OSP with SAML
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 deploy 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.
Access Manager supports a number of authentication methods, such as name/password, RADIUS token-based authentication, X.509 digital certificates, Kerberos, risk-based authentication, Time-Based One-Time Password (TOTP), social authentication, and OpenID Connect.
If you use the Identity Vault as your authentication service, users with the names (CN) 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 or to the Access Manager authentication service. The OSP or the Access Manager service authenticates the user, either by asking the user for a name/password or, if so configured, by asking the Kerberos or a SAML provider to authenticate the user. The authentication service 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.
The authentication service and Kerberos ensure that users only need to log in once to create a session with Identity Governance and Identity Reporting. If the users’ session’ time out, authorization occurs automatically and without the users intervening.
Identity Governance allows you to configure the users’ logout experiences to be the same. If the option Use Logout Landing page is set to True, the users in a Kerberos environment can log out and the authentication service does not reauthorize the users. Identity Governance presents the users 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 users to the login window and the authentication service reauthorizes the users’ sessions.
Using a SAML 2.0 identity provider (IDP) with OSP can provide SSO for multiple applications, such as applications beyond 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 results in the browser displaying the "logged out" page for the IDP.
For OSP and SSO to function, you must install OSP. Next 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.
Identity Governance can use the 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:Identity Governance always uses an authentication service as the login mechanism, even in a non-SSO environment.
Identity Governance can use the Access Manager authentication service, which supports several authentication methods. For a list of the authentication methods, see the Access Manager documentation. With Access Manager, you can provide single sign-on access among Identity Governance and other applications, such as Identity Manager Home and Provisioning Dashboard. All requests to Access Manager use the http or https protocols.
NOTE:Identity Governance always uses an authentication service as the login mechanism, even in a non-SSO environment.
Identity Governance can use Access Manager to connect with OSP as the authentication service. With Access Manager, you can provide single sign-on access among Identity Governance and other applications in your environment that use Access Manager for authentication.
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 located 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
in NetIQ Identity Governance Administrator Guide.
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. 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 or Access Manager with an LDAP server. By default, if you select SSL for LDAP protocol or TLS for audit protocol, the OSP installation program places the TLS/SSL trust certificates in /opt/netiq/idm/apps/osp/osp-truststore.pkcs12 or c:\netiq\idm\apps\osp\osp-truststore.pkcs12. The OSP installer provides a keystore that houses several symmetric keys and key pairs for signing, encryption, and, when necessary, TLS. The OSP keystore is located at /opt/netiq/idm/apps/osp/osp.pkcs12 or c:\netiq\idm\apps\osp\osp.pkcs12.
By default, the Identity Governance and Identity Reporting installation program places TLS/SSL trust certificates in /opt/netiq/idm/apps/tomcat/conf/apps-truststore.pkcs12 or c:\netiq\idm\apps\tomcat\conf\apps-truststore.pkcs12. This file stores certificates from the following secured servers:
Authentication server when you specify https for OSP or when you use Access Manager for authentication and when the authentication server is on a different server than Identity Governance or Identity Reporting
Identity Governance server when installing only Identity Reporting, specifying https, and the server or port differs from the Identity Reporting server or port
SMTP server when specifying SSL for use and the port is valid
Audit server when specifying TLS
Application server when specifying https
Both the GUI and console installation modes display the certificate details and ask for confirmation of each certificate retrieved. The silent installation mode imports certificate files specified in the silent properties file.
To use SAML 2.0 authentication, you must manually install the SAML identity provider’s TLS/SSL certificate in the trust store that you want to use. When using a Certificate Authority (CA) to issue certificates for the LDAP server, SAML IDP, or NetIQ Advanced Authentication servers, you can install the CA's trusted root certificate into the trust store and remove any server-specific certificates. For more information, see Section 3.2, 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: /opt/netiq/idm/apps/configupdate/configupdate.sh
Windows: C:\netiq\idm\apps\configupdate\configupdate.bat
Next, modify the keystore settings in the configuration utility. For more information, see Running the Identity Governance Configuration Utility.