8.2 Preparing One SSO Provider for Use

In some installation scenarios, you must take additional steps to prepare OSP for use with Identity Governance. For example, running OSP in an environment without Identity Manager or using Active Directory as your LDAP identity service require some additional steps.

8.2.1 Ensuring the Identity Governance Configuration Update Utility Can Run OSP

When you run OSP on a different Apache Tomcat server than Identity Governance, and you do not have Identity Manager in your environment, you must ensure that the Identity Governance Configuration Update utility has the appropriate values to run OSP. The Identity Governance Configuration Update utility (configupdate.sh or configupdate.bat) contains the settings that allow OSP to function as well as settings for Identity Governance.

The installation programs for Identity Governance, OSP, and Identity Reporting modify the following properties in the Identity Governance Configuration Update utility during the following conditions:

Table 8-1 Identity Governance Configuration Update Utility Properties

Properties

Conditions

use_ssl=true if LDAP is secured

Only the OSP installer sets this option. The Identity Governance and Identity Reporting installers preserve the existing value.

use_ssl=false if LDAP is not secured

Only the OSP installer sets this option. The Identity Governance and Identity Reporting installers preserve the existing value.

edition=none

Limits the pages that the Identity Governance Configuration Update utility displays. The alternative values are standard and advanced.

sso_apps=' '

Property is usually missing entirely. Identity Governance and Reporting are on this server. If the property value is empty, it removes the SSO Clients tab from the Identity Governance Configuration Update utility.

sso_apps='ig'

Identity Governance is on a different server. Reporting exists on this server or no server. The tab title displays as IG SSO Clients.

sso_apps='ig,rpt'

Identity Governance and Reporting are on different servers. The tab title displays as IG SSO Clients.

sso_apps='rpt'

Reporting is on a different server. The tab title displays as Reporting SSO Clients.

force_no_osp=true

OSP is not on this server. This property removes the Identity Vault tab from the Identity Governance Configuration Update utility.

force_no_osp=false

OSP is on this server. The Identity Governance Configuration Update utility displays the Identity Vault tab.

reporting_admins_app=

Reporting is not on this server.

reporting_admins_app=ig

Reporting is on this server.

For more information, see SSO Clients Parameters in the NetIQ Identity Manager Setup Guide for Linux.

To update properties in the Identity Governance Configuration Update utility:

  1. Create a backup copy of the ism-configuration.properties file.

    • Linux: Default location in /opt/netiq/idm/apps/tomcat/conf

    • Windows: Default location in C:\netiq\idm\apps\tomcat\conf

  2. In a text editor, open the configupdate.sh.properties or configupdate.bat.properties to update the values.

    • Linux: Default location in /opt/netiq/idm/apps/configupdate/configupdate.sh.properties

    • Windows: Default location in C:\netiq\idm\apps\configupdate\configupdate.bat.properties

    1. In the file, modify the properties to the following values:

      • Change is_prov to false

      • (Conditional) Change use_ssl to false, if your LDAP server is not set up for SSL communication

      • (Option) Change use_console to true, if you want to run the utility in console mode, otherwise change use_console to false for opening the Identity Governance Configuration Update utility in guided mode

    2. Save and close the file.

  3. Update settings in the Identity Governance Configuration Update utility.

    1. Launch the Identity Governance Configuration Update utility.

      • Linux: Default location in the /opt/netiq/idm/apps/configupdate

        ./configupdate.sh

      • Windows: Default location in C:\netiq\idm\apps\configupdate

        configupdate.bat

    2. Select SSO Clients.

    3. Under Reporting, specify values for the following parameters:

      NOTE:Regardless whether you use Identity Reporting, the utility requires values in these fields.

      • OAuth client ID

        For example, rpt

      • OAuth client secret

      • URL link to landing page

        For example, http://123.456.78.90:8180/#/landing

      • URL link to Identity Governance

        For example, http://123.456.78.90:8080/#/nav

      • OSP Oauth redirect url

        For example, http://123.456.78.90:8180/IDMRPT/oauth.html

    4. Under DCS Driver, specify values for the following parameters:

      NOTE:Regardless whether you use Identity Reporting, the utility requires values in these fields.

      • OAuth client ID

        For example, dcsdriver.

      • OAuth client secret

    5. To save your changes, select OK.

    6. Update the settings for Identity Vault and Authentication, as needed.

    7. (Conditional) If this is the first time you run the Identity Governance Configuration Update utility, under Authentication, go to Advanced Settings and enter the bootstrap administrator password. By doing this, the adminusers.txt file is not overwritten or deleted. If you do not do this, you will not be able to login as bootstrap administrator when you restart Apache Tomcat.

8.2.2 Preparing OSP to Use an Active Directory LDAP Server

To use Active Directory for your LDAP Identity Vault, you need to update the settings using the Identity Governance Configuration Update utility.

  1. Ensure that you have prepared the Identity Governance Configuration Update utility for OSP. For more information, see Section 8.2.1, Ensuring the Identity Governance Configuration Update Utility Can Run OSP.

  2. Stop Apache Tomcat, if it is running. For more information, see Section 3.4.3, Starting and Stopping Apache Tomcat.

  3. Launch the Identity Governance Configuration Update utility.

    • Linux: Default location in the /opt/netiq/idm/apps/configupdate

      ./configupdate.sh

    • Windows: Default location in C:\netiq\idm\apps\configupdate

      configupdate.bat

  4. Select Reporting > Identity Vault Settings > Identity Vault User Identity > Login Attribute.

  5. For Login Attribute, specify the attribute in Active Directory that you want to use for logging in to Identity Governance. For example, sAMAccountName.

    NOTE:This value is case-sensitive.

  6. To save your change, select OK.

  7. Update settings in the Identity Governance Configuration utility:

    1. Launch the Identity Governance Configuration utility.

      • Linux: Default location in /opt/netiq/idm/apps/idgov/bin

        ./configutil -password database_password

      • Windows: Default location in C:\netiq\idm\apps\idgov\bin

        configutil -password database_password

    2. Select Security Settings.

    3. For Auth Matching Rules, add the same attribute from Active Directory that you specified for Login Attribute in Step 5.

      Do not delete dn. For example, the setting should now list dn and sAMAccountName.

    4. Select Save.

  8. Continue with the post-installation tasks, as required.

8.2.3 Extending the Schema for OSP in the Identity Service not Part of Identity Manager

If you have integrated with Identity Manager you can skip this section. To have OSP authentications work you must manually extend the schema in the identity service that is not part of the Identity Manager deployment.

WARNING:Work with your directory administrator to properly extend the schema on the server or data corruption can occur.

The OSP installation places the files required to extend the schema in the following default directory:

  • Linux

    • Active Directory: /opt/netiq/idm/apps/osp/osp-extras/schema/ad/osp_ext.ldif

    • eDirectory: /opt/netiq/idm/apps/osp/osp-extras/schema/edir/osp.sch

  • Windows

    • Active Directory: c:\netiq\idm\apps\osp\osp-extras\schema\ad\osp_ext.ldif

    • eDirectory: c:\netiq\idm\apps\osp\osp-extras\schema\edir\osp.sch

To manually extend the schema on the eDirectory server, see Manually Extending the Schema. To manually extend the schema on the Active Directory server, see How to Extend the Schema.

8.2.4 Configuring OSP to Work with AD FS

Identity Governance supports AD FS as an identity service as long as AD FS is pointing to eDirectory or Active Directory. You must perform additional configuration steps for OSP and AD FS for this integration to work. There are requirements that you must meet before starting the configuration process.

Requirements for Configuring OSP to Work with AD FS

Ensure that you meet the following requirements that you must meet before you can configure OSP to work with AD FS.

  • Ensure that AD FS uses the same TLS version that the Apache Tomcat instance for Identity Governance uses for both incoming and outgoing communication. By default, Identity Governance uses TLS 1.2 and by default AD FS uses TLS 1.0. If AD FS uses a lower version than what Identity Governance uses it can cause issues with the integration. For more information, see Managing SSL/TLS Protocol and Cipher Suites for AD FS.

  • Ensure that Identity Governance is using https because AD FS requires it. For more information, see Section 3.8, Securing Connections with TLS/SSL.

  • Ensure that you are using Identity Governance 3.6 or later.

Configuring OSP to Provide SAML Authentications to AD FS

To configure OSP to provide authentications to AD FS you must perform configuration steps for OSP and AD FS. The following procedure contains information to match the users on the email attribute from Active Directory using a local Active directory server. You must change the custom rule examples for your environment.

  1. Ensure that you meet the requirements for this integration before proceeding. For more information, see Requirements for Configuring OSP to Work with AD FS.

  2. Configure the OSP server to provide SAML authentications to AD FS.

    1. Ensure that Apache Tomcat is running on the OSP server.

    2. Launch the Identity Governance Configuration Update utility on the OSP server. For more information, see Section 14.1.4, Using the Identity Governance Configuration Update Utility.

    3. Click the Authentication tab.

    4. Click Show Advanced Options at the end of the page.

    5. Under Authentication Method > Method select SAML 2.0.

    6. Use the following information to configure OSP to use SAML 2.0:

      Mapping Attribute

      Specify the attribute listed is the one you want to use to map the user accounts to Access Manager. The default value is mail.

      Landing Page

      Select where the landing page for your users is internal, external, or if there is not one. The default value is None.

      Metadata source

      Select URL to use the Access Manager metadata.

      Metadata URL

      Specify the AD FS metadata URL in this field.

      https://adfs-server/FederationMetadata/2007-06/FederationMetadata.xml
      Load on save

      Select this option to load the metadata.

    7. Under the Identity Governance Bootstrap Administrator heading, ensure that you are using an LDAP-based bootstrap administrator account. For more information, see Section 4.1.1, Using the Bootstrap Administrator.

    8. Click OK.

    9. Click Yes to accept the certificate.

    10. Restart Apache Tomcat on the OSP server. For more information, see Section 3.4.3, Starting and Stopping Apache Tomcat.

    11. Ensure that Apache Tomcat is running on the OSP server before proceeding.

  3. Create a relying party trust in AD FS to the OSP server using the OPS metadata.

    1. Create the relying party trust in AD FS following the Microsoft documentation. For more information, see Creating a Relying Party Trust.

    2. Use OSP metadata URL to finish the configuration. The default location of the URL is:

      https://osp-server:port/osp/a/idm/auth/saml2/spmetadata

    3. At the end of the configuration, ensure that you select Configure claims assurance policy for this application.

    4. (Conditional) If the Configure claims assurance policy configuration does not automatically load, right click on the Relaying Party Trust you created in Step 3.a, then select Edit Claims Insurance Policy.

    5. Add two custom rules to have AD FS send the email attribute and a local Active Directory server information to the OSP server. For more information, see AD FS 2.0 Claim Rule Language Primer.

      Sending the email attribute

      Use the following information to create the first custom rule to send the email attribute:

      Name

      Specify a name for the rule.

      Provide the Custom Rule

      The following is a sample rule that you might need to edit for your environment.

      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("mail", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";mail,userPrincipalName;{0}", param = c.Value);
      Sending Via SAML

      Use the following information to create the second rule to send the attribute to the OSP server via SAML:

      Name

      Specify a name for the custom rule.

      Provide the Custom Rule

      The following is a sample rule that you must edit for your environment.

      c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://adfs-server/adfs/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "https://osp-server:osp-port/osp/a/idm/auth/saml2/metadata", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spprovidedid"] = c.Value);

8.2.5 Configuring OSP to Use Google reCAPTCHA

To configure OSP to use Google reCAPTCHA, you need a Google account to sign in to Google, and then sign up for an API key pair. For more information about reCAPTCHA, and how to create the API key pair, see the Google reCAPTCHA Developer’s Guide. After you create the API key pair, you can configure OSP to work with Google reCAPTCHA.

NOTE:The API key pair includes a site key and a secret key, which are required to perform this configuration procedure.

  1. Launch the Identity Governance Configuration Update utility on the OSP server. For more information, see Section 14.1.4, Using the Identity Governance Configuration Update Utility.

  2. Click the Authentication tab.

  3. Click Show Advanced Options.

  4. In the Authentication Method section, perform the following steps:

    1. Select Name and Password from the Method list, if it is not already selected.

    2. Select Enable reCAPTCHA, and then enter the appropriate values in the following fields:

      Number of attempts before required

      Type the number of access attempts required before reCAPTCHA is required for access. The default value is 0.

      Site key

      Copy and paste the site key created when you created the API key pair.

      Private key

      Copy and paste the secret key created when you created the API key pair.

  5. Click OK, and then accept the Google certificate chain.

  6. Restart Apache Tomcat on the OSP server. For more information, see Section 3.4.3, Starting and Stopping Apache Tomcat.

To verify you correctly configured OSP to work with reCAPTCHA, open a browser and access either Identity Governance or Identity Reporting. If you retained the default 0 attempts in this procedure, reCAPTCHA appears immediately. Otherwise, reCAPTCHA appears after the number of access attempts you defined in this procedure.