Step 4: Register ALM as SP in IdP

Prerequisite: you already complete Step 3: Deploy SSO Components.

This step is to register ALM as SP from the IdP side. The configuration details vary from an IdP to another. You should check the IdP document for more information.

Generally, you should at least complete the following tasks.

If you use SAML2 as the federation protocol

  1. Create a client that uses SAML2 as the client protocol.

  2. Obtain the ALM SP metadata and share it with the IdP.

    1. Obtain the SP metadata from the following directory: http(s)://{server}:{port}/osp/a/{IdP name}/auth/saml2/sp-metadata.

      If ALM is deployed in a cluster environment, obtain the SP metadata on all ALM nodes.

    2. Save the data as an XML file.

    3. The SP metadata will be used in IdP configuration to build trust between SP and the IdP. For additional IdP settings, see the documentations for the IdP.

  3. Create mappers to map the user attributes that are returned by the IdP in SAML assertions to the equivalent ALM attributes.

    Make sure you map the IdP attribute that can uniquely identify IdP users to the ALM attribute IdentityKey.

    ALM requires that NameID format should be emailAddress.

    If you map an ALM attribute to a different IdP attribute than what you map it to in the SSO configuration tool (as in Step 4: Register ALM as SP in IdP), the mapping in the SSO configuration tool prevails. For example, if the ALM attribute ALMDescription is mapped to Field A in the SSO configuration tool, ALM will use the value of Field A in the SAML assertions to update the ALM attribute ALMDescription.

    The attributes are case-sensitive. The SAML response must be signed.

    For example, see Sample SAML response.

If you use OIDC as the federation protocol

  1. Create a client that uses OIDC as the client protocol.

  2. Add the ALM SP redirect URI to the client as a valid redirect URI.

    The ALM SP redirect URI is in the following format: {Communication_Schema}://{Communication_FQDN}:{Communication_Port}/osp/a/{idp_id} /auth/oauth2/landingpad

  3. Create mappers to map the user attributes that are returned by the IdP in OIDC tokens to the equivalent ALM attributes.

    Make sure you map the IdP attribute that can uniquely identify IdP users to the ALM attribute IdentityKey.

    If you map an ALM attribute to a different IdP attribute than what you map it to in the SSO configuration tool (as in Step 4: Register ALM as SP in IdP), the mapping in the SSO configuration tool prevails. For example, if the ALM attribute ALMDescription is mapped to Field A in the SSO configuration tool, ALM will use the value of Field A in the OIDC tokens to update the ALM attribute ALMDescription.

Sample SAML response 

<samlp:Response>
	<saml:Assertion>
...
...
...
		<saml:Subject>
			<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">sa@yopmail.com
                       </saml:NameID>
			<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
				<saml:SubjectConfirmationData 
					InResponseTo="idhSHtlcKqu3Xn8CpOIRc658-cnAI" 
					NotOnOrAfter="2019-04-30T09:11:36.887Z" 
					Recipient="https://shcappsvm76.hpeswlab.net:9443/osp/a/alm/auth/saml2/
                                           spassertion_consumer"/>
			</saml:SubjectConfirmation>
		</saml:Subject>
		<saml:Conditions NotBefore="2019-04-30T08:51:36.887Z" NotOnOrAfter="2019-04-30T08:52:36.887Z">
			<saml:AudienceRestriction>
				<saml:Audience>https://shcappsvm76.hpeswlab.net:9443/osp/a/alm/auth/saml2/metadata
                               </saml:Audience>
			</saml:AudienceRestriction>
		</saml:Conditions>
		<saml:AuthnStatement 
			AuthnInstant="2019-04-30T08:51:38.887Z" 
			SessionIndex="5e968b7c-c2ad-41e6-81fb-3feb38644bcf::dfb1c06f-89e1-42ca-a6b0-f3ff41bb2fbd">
			<saml:AuthnContext>
				<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
                               </saml:AuthnContextClassRef>
			</saml:AuthnContext>
		</saml:AuthnStatement>
		<saml:AttributeStatement>
			<saml:Attribute 
				Friendly="IdentityKey" Name="IdentityKey" 
				NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
				<saml:AttributeValue 
					xmlns:xs="http://www.w3.org/2001/XMLSchema" 
					xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">**
                              </saml:AttributeValue>
			</saml:Attribute>
		</saml:AttributeStatement>
	</saml:Assertion>
</samlp:Response>

FAQ

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.

Next steps: