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 {ALM repository folder}\sa\DomsInfo\osp\ directory.

   For example, for the default alm IdP, open the {ALM 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 ALM 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 ALM 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 ALM is actively listening on this port.

     2. Restart the ALM service on every ALM node.

Root cause: The forceAuthAtIDP attribute has been enabled on the ALM 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}

A:

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

Solution: Make sure the correct SP metadata can be loaded from ALM. And ALM 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.

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 ALM has been established successfully. The only problem is that the IdP user cannot be validated by ALM. ALM users and IdP user are mapped using the IdentiyKey values. If the IdP does not provide the IdentityKey value the SAML response, ALM cannot map the IdP user to any ALM 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.

A: In the web browser, type the ALM 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 ALM is established successfully.

A:

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

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

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

A: If you set Enable Local Authentication to YES in *Enable Local Authentication, 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 a chance to log in to ALM as a local user to fix the IdP configuration so that IdP users can log in to ALM.

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.

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 ALM 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 an ALM local user and local authentication is enabled.

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.

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

A: Switching to the SSO mode does not modify the usernames of existing users. They can still access the same resources as they do when ALM runs in a 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.

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 a non-SSO mode. If a 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.

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 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 Configure service provider and Configure identity providerin the SSO Configuration Tool.

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.