This article provides information and instructions for using Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) with Single Sign-On (SSO) in your account.
SAML
SAML 2.0 is an SSO protocol that ensures the secure transfer of information pertaining to authentication and authorization. Two parties are involved with this exchange:
-
The Identity Provider (IDP) verifies who is logging in to your Higher Logic Thrive Community (Thrive Community) site. The IDP can be your AMS/CRM system or an external application that works closely with your AMS/CRM.
-
The Service Provider (SP) is usually a third-party system that is integrated with your main site. In this case, it is your Thrive Community site.
An exchange of IDP metadata from your IDP and Higher Logic's SP metadata must occur to begin this setup.
Notes
All SP requests and IDP responses must be signed to ensure the integrity of SAML assertions and SP requests.
Higher Logic will sign all authentication and logout requests which can be validated using the public certificate contained in the provided SP metadata.
Higher Logic requires that all SAML responses be signed by the IDP and that IDP responses can be verified using the public certificate contained in the IDP-provided metadata.
Higher Logic uses the value of NameID as the unique identifier for each user in the Thrive Community site. The value of NameID that is contained with the SAML assertion must map to the users' unique identifiers in your AMS/CRM. If any of these values do not match, the associated users will not be able to access the Thrive Community site.
OIDC
OIDC is an identity layer that allows for the verification of end-users' identities of based on the authentication performed by an authorization server.
The following requirements must be met if you are using an OIDC Provider (OP) such as Okta, Auth0, or AzureB2C.
NOTE: If you are using IdentityServer4 or some other solution, have your technical resource review these requirements.
Notes
- Your OP must have a /.well-known/openid-configuration URI. This URI is necessary to configure your Thrive Community site's OIDC SSO.
NOTE: If your OIDC provider does not have this URI or if this URI does not accurately describe the behavior of your OP, Higher Logic will not be able to support your OP's OIDC implementation. - When Higher Logic initiates an authentication request, it will pass a nonce as a query string parameter. This nonce must be returned in the user's id_token.
- When Higher Logic makes the authentication request, it will use the following as scopes: openid and profile.
- Higher Logic will only support authorization code flow (grant_type: authorization_code).
- After receiving the authorization code, Higher Logic will make the request to the token URI using basic auth.
- When receiving the id_token from the token URI, Higher Logic will verify the cryptographic signature of the token. Signatures must be made with RS256 encryption. Any id_token that is not signed will be considered invalid.
- The following claims will be validated in each id_token:
- iss (issuer): the issuer specified in the claim must be the issuer that is specified by the /.well-known/openid-configuration URI
- aud (audience): aud must match the client client_id supplied to Higher Logic
- exp (expiration): exp must be a valid UTC date-time value
- nonce: the nonce that is passed in the authentication request must be returned as a claim in order to verify that the id_token belongs to the user requesting authentication
- After the id_token must contain all information necessary to resolve the user identity because after it has been received and validated, no other requests will be made to resolve user identity.
- When resolving user identity, the sub claim within the id_token must be the unique identifier of the user and the Legacy Contact Key of the user in the Thrive Community site. Other claims will not be used to uniquely identify users.