Any SAML 2.0 provider

Use this for an identity provider the portal does not list by name. The portal has its own guide for twenty providers, AD FS, Auth0, Keycloak and Shibboleth among them (the list). In the portal, choose SAML 2.0 under Enterprise SSO and Start with SAML 2.0.

What to create

In your provider, create a new SAML 2.0 application. Providers call it a service provider, a relying party trust or an application. Enter:

If your provider imports service-provider metadata, give it the portal's SP metadata URL (https://…/sso/saml/…/metadata) instead: it carries the entity ID and the ACS URL in one document.

The response must:

• have a signed assertion. Sign the assertion itself, or both the assertion and the response. A response that is signed while its assertion is not is refused.

• carry a NameID. It identifies the person, so it must not change.

• carry the person's email address, in either of two places:

  • an attribute named email, mail, emailAddress, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress or urn:oid:0.9.2342.19200300.100.1.3, or
  • the NameID, in the urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress format. That is the default for Okta and Google Workspace, so they need no attribute.

  When both are sent, the attribute wins. A NameID in any other format (persistent, transient, unspecified) is never read as an email address, so with one of those you must send the attribute.

• optionally send a display name as name or displayName. First and last name are accepted and ignored.

Give the application to the people who should sign in this way.

What to bring back

Your provider's metadata URL, or its metadata XML, pasted into Metadata URL or XML. Without metadata, choose Enter the values by hand instead and fill in:

Related

• Enterprise SSO — the portal's five steps.
• SAML certificate renewal — before the signing certificate expires.
• Any OpenID Connect provider — if your provider speaks OpenID Connect instead.