A: IdP SAML certificate: ALM does not import the IdP SAML certificate. ALM only requires the IdP metadata in which the IdP certificates are contained.

IdP SSL certificate: It should be imported into the JVM key store on which ALM runs.

ALM SAML certificate: It is used to encrypt and decrypt the SAML requests and responses between ALM and IdPs.

ALM/ALM's reverse proxy SSL certificate: It should be imported into the JVM key store on which ALM runs.

A: Generally we suggest you get the SAML certificate from an authorized organization so that you can get a safer certificate. But if your organization doesn’t require very high security policies, you can create an SAML certificate by yourself.

To generate a self-signed SSL certificate using the keytool command on Windows, Mac, or Linux:

1. Open a command prompt or terminal and run this command:

   keytool-genkey-keyalgRSA -alias <alias> -keystoreselfsigned.jks-validity <days> -keysize2048

   where <alias> indicates the name for the certificate; <days> indicates the number of days for which the certificate will be valid.

2. Enter a password for the keystore file. Note down this password as you need it when configuring the server.

3. When prompted for the first name and last name, enter the domain name of the server. For example, myserver or myserver.mycompany.com.

4. Enter the other details, such as Organizational Unit, Organization, City, State, and Country.

5. Confirm that the information entered is correct.

6. When prompted with "Enter key" password for <tomcat>, press Enter to use the same password as the keystore file password.

7. Run this command to verify the content of the keystore file:

   keytool-list -v -keystoreselfsigned.jks

8. When prompted, enter the keystore file password.

The certificate you generate is named as selfsigned.jks. Do not modify its extension name. Verify that the "Owner" and "Issuer" are the same. Keep the alias, key password and keystore file password in your secure place because you will need them in the SSO Configuration Tool for uploading or deleting the certificate.

A: The error message indicates the SP service is not started successfully. The SSO components have been deployed successfully, but some settings in the alm IdP are not correct. You should fix the settings and restart the ALM service.

A: The ALM SSO components are deployed as additional web components in the same web container as the ALM service. Same as the ALM service, the logs of the SSO components are written to the wrapper log. However, the log level is configured in a different way.

1. Open the SP configuration file in the ALM repository: {ALM repository}\sa\DomsInfo\osp\basic.properties.
2. Set "logging.level=ALL" so that all the debug level logs can be captured into the wrapper.log file. Do not modify other values in the SP configuration file.
3. Restart ALM and login ALM again.
4. Open the latest wrapper.log file to look for logs related to "osp".
5. If you need more details, check the two properties files under {ALM repository}\sa\DomsInfo\osp\.

A: ALM requires the assertion attribute of "IdentityKey". It is used by ALM to uniquely identify IdP users. Any IdP attribute that can uniquely identify IdP users, such as email, universal ID, or employee ID, can be mapped to "IdentityKey".

If the value of the mapped unique IdP attribute gets updated in the IdP side, the change should be manually updated in the ALM side. In 15.0.1, if auto user-provisioning is enabled, the IdP user information changes will be updated automatically to the located matching ALM user.

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