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

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.

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 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.

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 to the project data. The SSO authentication only changes user management.

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.

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. See https://www.eclipse.org/jetty/documentation/9.4.x/configuring-connectors.html for details.

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 {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 IdP - alm, and Step 3: Deploy SSO Components in the SSO Configuration Tool.