Step 7: Enable SSO

Prerequisite: Step 6: Validate IdP.

This step is to enable SSO. This should be done only after the "alm" IdP is validated successfully. After you enable SSO, you can add other IdPs if needed.

To enable SSO, turn on the Enable SSO toggle in the top right corner of the SSO Configuration Tool. Once SSO is enabled, it cannot be disabled.

Back to top

FAQ

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

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

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

https://marketplace.microfocus.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 Step 1: Configure ALM as SP, ALM authenticates the local users in the ALM side and authenticate the IdP users in the IdP side. If you are an ALM local user, ALM allows you to enable SSO even when the IdP "alm" does not pass the validation, because in this case you still have the change to login ALM as a local user to fix the IdP configuration so that IdP users can login ALM.

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 ALM 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 via either SSO authentication or local authentication.

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

  • Be mapped to an IdP user.
  • Be configured as an ALM local user and local authentication is enabled.

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

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

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

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

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

A: Switching to SSO mode does not modify the usernames of existing users. They can still access the same resources as they do when ALM runs in 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 ALM 15.0 after getting authenticated in IdP, why does the web browser report "431 request header fields too large"?

A: When ALM 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 ALM runs in non-SSO mode. If user's reverse proxy or ALM has restricted the request header size to be smaller than the actual size, this issue happens.

To solve this issue, modify the ALM 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 ALM repository folder changes after SSO is enabled?

A: To manually modify the SSO configuration files:

  1. In the qcConfigFile.properties file located in {installzation_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 ALM 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 ALM 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 ALM repository}\sa\DomsInfo/osp/alm.properties" name="propertiesFile"/>

  5. Perform Step 1: Configure ALM as SP, Step 2: Configure default IdP, and Step 3: Deploy SSO components in the SSO Configuration Tool.

Note: For details about how to change the ALM repository, see the KB article.

Q: After SSO is enabled, if I log in to ALM using Chrome or Edge (version 86 and later), I'm redirected to the IdP login page. After logging in the IdP, Chrome or Edge keeps redirecting me between ALM 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

Next steps: