Before you set up SAML v2.0 in AM, you should:
Know which providers will participate in circles of trust.
Know how AM installations act as identity providers or service providers.
Define how to map shared user attributes in identity information exchanged with other participants in a circle of trust. Local user profile attribute names should map to user profile attribute names at other providers.
For example, if you exchange user identifiers with your partners, and you call it
uid, whereas another partner calls it
userid, then you map your
uidto your partner’s
Agree with other providers on a synchronized time service.
Determine whether your session state configuration limits your usage of certain SAML v2.0 profiles. For more information, see Session state considerations.
SAML v2.0 functionality uses a combination of the CTS and browser-based data to store the progress of SAML v2.0 single sign-on SSO operations.
This combination enables AM instances to continue single sign-on flows that started at a different instance, without the need for sticky load balancing in most scenarios.
Single sign-on progress is stored in a JSON web token (JWT) in the browser’s local storage. The browser must support the localStorage API to handle SSO without the need for sticky load balancing of the AM instances. You must configure sticky load balancing to support SAML v2.0 SSO with clients that do not support local storage, and on IdP proxy implementations.
You can enable local storage support in WebView components on Android by using the following property:
You cannot use local storage when using multiple WebView components simultaneously. For more information, see WebSettings - setDomStorageEnabled in the Android Developers documentation.
Performing single log out (SLO) operations when there is more than a single AM instance has the following caveats:
AM instances cache information about SLO progress in memory. After the initial request, you must send each subsequent request in an SLO flow to the same instance; for example, by enabling sticky load balancing.
Use the HTTP-POST or HTTP-Redirect bindings for SAML v2.0 single logout (SLO). The SOAP binding is not supported.
The following table summarizes the high-level tasks required to configure SAML v2.0:
Configure an SP, an IDP, and a CoT
The first step is deciding if AM is the SP, the IDP, or both, and/or what metadata you need to import from other providers.
For example, if AM is the IDP for another service in your environment, you will have to import the metadata of the remote SP.
Ensure the SPs and IDPs that work together share the same CoT.
Make sure your providers are secure
Configure signing and encryption secrets for your environment.
Configure your environment for SSO and SLO
AM provides two options for implementing SSO and SLO: integrated mode, and standalone mode.
There are several considerations to make before deciding which mode is more appropriate for your environment.
Decide how to federate identities
AM supports different ways to federate identities depending of the configuration, and whether they exist or not in the SP.