Share this page

# Validate identity provider and enable SSO

Prerequisite: Set up your profile

This section describes how to enable SSO.

In this topic:

## Validate an IdP

To enable SSO, you first validate the alm IdP.

You validate an IdP to verify the IdP configuration and the communication between SP and the IdP.

Note: If you enable local authentication and select Local Authentication as the authentication method, you can enable SSO directly without validating the IdP.

Prerequisites

Ensure the following before you validate an IdP.

- At least one site admin user is already mapped to an IdP user.

- The OpenText Application Quality Management and IdP URLs are added to the trusted URLs.

Validate an IdP using the wizard

You can validate an IdP using the SSO Configuration Wizard. It is applicable to non-SaaS environments only. For SaaS environments, see Send validation URL to IdP users for validation.

To validate an IdP using the wizard:

1. In the Enable SSO step, from the Identity Provider field, select the IdP you want to validate.
2. At the bottom of the step, click Validate.

3. In your IdP login page, enter your IdP username and password.

4. In the Validation Status field, check the validation status:

   Status | Description
   --- | ---
   Pending Validation | The initial status of SSO validation.
   Validation Success | The validation passes.
   Validation Failure | The validation fails. Failure details are displayed below the Validation Status field.

Send validation URL to IdP users for validation

You can copy the validation URL and send it to IdP users for remote validation.

Note: In SaaS environments, you can only send the validation URL to IdP users for SSO validation.

1. In the Enable SSO step, from the Identity Provider field, select the IdP you want to validate.
2. At the bottom of the step, click Copy Validation URL.

3. In the Copy Validation URL dialog box, click Copy and send the link to IdP users.

   When the IdP users open the link, they are redirected to the IdP login page. After entering the IdP username and password, they are redirected to a page that tells whether or not the validation succeed, and if not, what the reasons are.

   If email notification is enabled, the specified site admin users can receive email about who accessed the SSO validation URL. For details, see Send Notification.

Back to top

## Enable SSO

After the alm IdP is validated successfully, you can enable SSO.

To enable SSO, in the bottom right corner of this step, click Enable SSO.

After you enable SSO:

- You cannot disable it.

- The Enable SSO step is renamed to SSO Validate, and the Enable SSO button disappears.

- You can add additional IdPs.

Back to top

## FAQ

Q: When I try to validate the IdP in the SSO Configuration Tool, I get the "SP metadata is not available or the URL inside SP metadata is not correct" error or the 401 error.

A: To troubleshoot this error, do the following:

1. In the {IdP name}.properties file, retrieve the osp.api.url parameter.

   The file is located in the {Repository folder}\sa\DomsInfo\osp\ directory.

   For example, for the default alm IdP, open the {Repository folder}\sa\DomsInfo\osp\alm.properties file to retrieve the osp.api.url parameter.

2. Run the following command to ping the osp.api.url on every node:

   `ping {osp.api.url}`

3. Verify the ping output:

   - If the ping command fails to obtain the URL and returns an network issue, request assistance from the network team for further diagnosis.

   - If the network team fails to provide workable solutions, try the following workaround:

     1. In the {IdP name}.properties file, change the osp.api.url parameter to the local address of the server. For example, osp.api.url= http\://localhost\:{http port number}/osp/a/{IdP name}

        To obtain the http port number, in the <installdir>server\conf\jetty.xml file, check the <Set name="port"<property name="jetty.port" default=....></set> line.

        Note: Make sure the HTTP communication is enabled in the jetty.xml file and the system is actively listening on this port.

     2. Restart the service on every node.

Q: Why is credential still required each time I log in after enabling SSO?

Root cause: The forceAuthAtIDP attribute has been enabled on the server.

A: Update the value of the forceAuthAtIDP attribute to false in the authcfg.xml file in the following directories:

- <installdir>\webapps\osp\ospconf\WEB-INF\conf\current\{tenant name}\services\

- <installdir>\osp\ospconf\WEB-INF\conf\current\{tenant name}\services\

For example, forceAuthAtIDP="${login.saml2.forceAuth:false}

Q: When I validated the "alm" IdP in the SSO Configuration Tool, the web browser redirected me to the IdP but reported an error as follows. Why?

A:

Root cause: Wrong SP metadata URL was registered in the IdP, so the IdP cannot recognize the SAML request sent from the system.

Solution: Make sure the correct SP metadata can be loaded from OpenText Application Quality Management. And OpenText Application Quality Management should be registered as SP in the IdP correctly before you validate the IdP. After the SP metadata is registered in the IdP, when validating the IdP, you will be redirected to the IdP login page correctly.

Q: Why did I fail to validate the IdP even when the IdP returned SAML response to OpenText Application Quality Management successfully?

A:

Root cause: The SAML response assertions did not contain the required assertion of "IdentityKey".

Solution: If the IdP returned SAML response, it means the trust between the IdP and OpenText Application Quality Management has been established successfully. The only problem is that the IdP user cannot be validated. OpenText Application Quality Management users and IdP user are mapped using the IdentiyKey values. If the IdP does not provide the IdentityKey value the SAML response, OpenText Application Quality Management cannot map the IdP user to any OpenText Application Quality Management user, and thus validation fails.

To solve the issue, in IdP, map IdentityKey as the SAML attribute with an IdP attribute that can uniquely identify the IdP user.

Q: How can I know the trust between IdP and OpenText Application Quality Management is established successfully?

A: In the web browser, type the SP URL like this: `{ALM host:port}/osp/a/alm/auth/app/`. If it redirects you to the IdP login page, and if after authentication it redirects you back to the SP page without error, it means SP has received SAML response from the IdP: the trust between IdP and OpenText Application Quality Management is established successfully.

Q: Why did I fail to log in through ALM Client Launcher after SSO is enabled in 15.0?

A:

Root cause: An old version of ALM Client Launcher was used.

Solution: Download the latest ALM Client Launcher to work with the 15.x SSO solution.

https://marketplace.opentext.com/appdelivery/content/alm-client-launcher

Q: Why can I still click the Enable SSO button even when I failed to validate the IdP "alm"?

A: If you set Enable Local Authentication to YES in *Enable Local Authentication, the system authenticates the local users in the OpenText Application Quality Management side and authenticate the IdP users in the IdP side. If you are a local user, OpenText Application Quality Management allows you to enable SSO even when the IdP "alm" does not pass the validation, because in this case you still have a chance to log in as a local user to fix the IdP configuration so that IdP users can log in.

Q: If some issues cause the failure of SSO authentication and I cannot open the SSO Configuration Tool, what should I do?

A: We recommend you enable local authentication so that, after SSO is enabled, local users can still login to fix the SSO configuration issues.

Q: Will I lose my local account after SSO is enabled?

A: Since 15.0.1, after SSO is enabled, all users get authenticated using either SSO authentication or local authentication.

The local accounts are still kept in the system after SSO is enabled. To get authenticated, every local account should meet either of the following requirements:

- Each local user is mapped to an IdP user.
- Each local user is configured as a local user and local authentication is enabled.

Q: Can I bypass the federated partnership and log in directly?

A: 15.0.1 and later support local authentication. When local authentication is enabled, site administrator can configure a user as a local user by specifying its IdP ID as "local": such local users can login directly.

Q: After SSO is enabled, what happens to the projects that were created and accessed before SSO is enabled?

A:There is no impact on the project data. The SSO authentication only changes user management.

Q: If I have been using the system for years, do I still have access to the same resources as I used to have?

A: Switching to the SSO mode does not modify the usernames of existing users. They can still access the same resources as they do under non-SSO mode.

They are just mapped to corresponding IdP users. The USERS table has 2 additional columns: US_IDENTITY_KEY and US_IDPID_NAME to keep the user mapping information for each user.

Q: When I try to access 15.0 after getting authenticated in IdP, why does the web browser report "431 request header fields too large"?

A: When 15 works in SSO mode, some additional IdP sessions and SP sessions are appended into the cookie of HTTP requests, which makes the request header size much bigger than it is when the system runs in a non-SSO mode. If a user's reverse proxy or the system has restricted the request header size to be smaller than the actual size, this issue happens.

To solve this issue, modify the Jetty settings to enlarge the request header size. Recommended size: 81920. To know more about how to configure "requestHeaderSize" of Jetty Connectors, see the Jetty documentation.

If reverse proxy also restricts the request header size, ask the network admin to modify the size.

Q: How to modify the SSO configuration files manually if the repository folder changes after SSO is enabled?

A: To manually modify the SSO configuration files:

1. In the `qcConfigFile.properties` file located in `{install_folder}`, update the value of "repositoryPath" to the new repository folder.

2. In the `wrapper.conf` file located in `{deployment_folder}/wrapper`, update the value of "wrapper.java.additional.34" to the following:

   `wrapper.java.additional.34=-Dalm.osp.framework.generic-properties-filename="{New repository}/sa/DomsInfo/osp/basic.properties"`

3. In the `basic.properties` file located in `{project repository folder}`, update the value of "oauth-keystore.file" to the following:

   `oauth-keystore.file={New repository}\\sa\\DomsInfo/osp/basic.pfx`

4. In the `ospcfg.xml` file located in `{project repository folder}`, update the value of name="propertiesFile" to the following:

   `<NamedValue value="{New repository}\sa\DomsInfo/osp/alm.properties" name="propertiesFile"/>`

5. Perform Configure service provider and Configure identity providerin the SSO Configuration Tool.

Note: For details about how to change the repository, see How to move the domain repository from one location to another when using TD for QC.

Q: After SSO is enabled, if I log in using Chrome or Edge (version 86 and later), I'm redirected to the IdP login page. After logging in to the IdP, Chrome or Edge keeps redirecting me between OpenText Application Quality Management and IdP.

A: Change the security setting in Chrome or Edge:

1. Enter "chrome://flags/" in Chrome or "edge://flags/" in Edge.
2. Search the keyword "SameSite by default cookies".

3. For Chrome: Set the Cookies without SameSite must be secure and SameSite by default cookies options to Disabled.

   For Edge: Set the SameSite by default cookies and Schemeful Same-Site options to Disabled.

Back to top

https://admhelp.microfocus.com Application Quality Management 8942
Tips to improve your search results... OpenText™ Application Quality Management Help Center OpenText™ Application Quality Management Help Center OpenText™ Application Quality Management Help 26.1 All View Local Help Center View Online Help Center Version: