Configuring SAML 2.0-compliant single sign-on

Before you configure Application Security to work with SAML 2.0 single sign-on, be aware of the following:

Application Security supports HTTP REDIRECT and HTTP POST bindings for inbound and outbound SAML messages.
SAML single logout is supported in Application Security. Logout responses and logout requests sent by IdP must be signed.
For successful SAML integration, the clocks on the client and server machines (IdP and SP) must be synchronized.

To configure Application Security to work with SSO that uses SAML 2.0:

If you are using an LDAP directory for users in Application Security and IdP, configure Application Security to use LDAP authentication. Otherwise, IdP users must match local users. For information, see LDAP user authentication.
If your IdP runs with SSL (https), configure Application Security to run with SSL. Otherwise, protocol switching while authenticating against IdP could interfere with authentication.
Prepare a public/private key pair to be used to digitally sign SAML messages and encrypt SAML Assertions. If your IdP does not require keys signed by a specific certification authority, you can generate your own self-signed key using, for example, OpenSSL or Java's keytool. The following example command generates a keystore that stores a self-signed key under a given alias:
```
keytool -genkeypair -alias <key_alias> ‑keyalg <RSA_or_EC algorithm> -keystore <keystore_filename> -storepass <password_to_protect_keystore> ‑keypass <password_to_protect_key> ‑validity <number_of_days_the_key_is_valid>
```
Make a note of the values for the alias and both passwords. You must provide them later in the Application Security Administration view.
Get SAML metadata from the IdP server and store it on the Application Security file system.
Open the metadata file and make a note of the entityID for your IdP EntityDescriptor (<EntityDescriptor entityID="THE_VALUE_YOU_ARE_LOOKING_FOR">).

Also check to see whether the metadata is signed (the <Signature> section is present). If the metadata is signed, the signature is verified with the PKIX validation algorithm and uses all public keys present in the keystore as trust anchors.

Ensure that you include the root CA certificate and intermediary CA certificates of the signature in your keystore.
Sign in to Application Security and, on the header, select Administration.
On the navigation pane, expand Configuration, and then select SSO.

You can configure only one single sign-on solution at a time.
From the Enabled SSO list, select SAML.

Provide the information described in the following table.

Field	Description
IdP metadata location	Location of your identity provider metadata (the metadata obtained in step 4). Examples On Windows systems: `file:///C:/fortify/federation-metadata.xml` On Linux systems: `file:///home/fortify/federation-metadata.xml` If you are integrating with Entra ID, enter the value shown in the App Federation Metadata Url field In Azure. (In the left pane in Azure, under Manage, select Single sign-on, and then select SAML. You can see the App Federation Metadata Url field under SAML Signing Certificate.) If your IdP is behind a proxy server, you must download IdP metadata to your local file system and reference it locally. Current SAML implementation does not support getting metadata over http proxy.
Default IdP	entityID of your IdP EntityDescriptor (from IdP metadata) If you are using the SCIM protocol to provision Application Security with user data from Entra ID, use the value shown in the Azure AD Identifier field in Entra ID. (You can see this field on the SAML-based Sign-on page under Set up <application_name>.)
SP entity ID	Service provider entity ID value must be a URL that does not exceed 1024 characters, and is globally unique across federations. OpenText recommends that you use the web address of a running Application Security instance.
SP alias	Service provider alias must include only alphanumeric characters, colons, dashes, and underscores. It cannot contain slashes, hash marks, semicolons, or question marks. Because this field value plays no significant role, you can specify any general value. For example, you can use `fortify_ssc`.
Keystore location	Location of your keystore that stores the key pair for signing SAML messages and encrypting SAML Assertions. Examples: For Windows: `file:///C:/fortify/keystore.jks` For Linux: `file:///home/fortify/keystore.jks` If IdP metadata is signed, the signature is verified with the PKIX validation algorithm and uses all public keys present in the keystore as trust anchors. Ensure that you include the root CA certificate and intermediary CA certificates of the signature in your keystore.
Keystore password	Keystore file password
Signing & encryption key	Signing/encryption key alias in the keystore file
Signing & encryption key password	Signing/encryption key password
SAML name identifier	Name of the element in the SAML assertion sent by IdP that holds the authenticated user's username, which matches the Application Security user's username. Use the NameID value if the username is released within the <NameID> element. If the username is released within one of the <Attribute> elements, provide the name value of the attribute. This information should be available or configurable in your IdP server.

Click SAVE.

Select the Enable IdP metadata signature verification checkbox after generating the metadata, that is, after step15.
Verify that the host.url property in <fortify.home>/<app_context>/conf/app.properties designates a URL that the IdP server can access.

The URL is used as a base URL to construct <AssertionConsumerService> and <SingleLogoutService> locations in Application Security SAML metadata.
If the SAML assertion sent from IdP is encrypted, make sure that the authentication response message is signed.

If you are integrating with Active Directory Federation Services (AD FS), set the IdP parameter SamlResponseSignature to the MessageAndAssertion (recommended) or MessageOnly value.
Recent Google Chrome™ or Chromium-based browsers default to a SameSite=Lax cookie policy, which means that cookies are not sent with sub-requests to third-party sites. As a result, single logout that is not initiated from Application Security does not work correctly.

Single logout initiated from Application Security works correctly, regardless of the cookie policy settings.

To make single logout work in Chrome or Chromium-based browsers, you must change the SameSite policy for session cookies to None.

This denotes a less secure policy than the default, so you must determine whether making the change is the best approach for your organization. To change the policy for container deployments, use the HTTP_SERVER_SAME_SITE_COOKIES environment variable. For non-container deployments, add <CookieProcessor sameSiteCookies="none"/> to the context section of your Tomcat configuration. For details, see the the Apache Tomcat 10 Configuration Reference documentation.
Restart Application Security.
Generate the Application Security (SP) metadata at <hostname>:<port>/<app_context>/saml/metadata/<SP_alias>.
Only if the IdP metadata is signed (the <Signature> section is present) (see, step 5), perform the following substeps else proceed with step 17:
1. In the Application Security go to the SSO configuration page and select the Enable IdP metadata signature verification checkbox to verify the IdP metadata signature using the IdP provided public key (X.509 Certificate).
2. Click SAVE.
3. Restart Application Security.
Open the metadata generated in the previous step (step 15) and verify that the location URLs in <AssertionConsumerService> and <SingleLogoutService> are accessible from the IdP server.
Upload the Application Security metadata to the IDP server.
Try to access <hostname>:<port>/<app_context>.

You are redirected to the IdP server, where you can enter your credentials. After successful authentication, the IdP server redirects you back to Application Security.

For information about how to obtain extra logging information related to SSO authentication, see Enabling debug logging for single sign-on authentication.