Frequently asked questions

No. We are not a registered InCommon Federation member.

No. The application does not consume InCommon federation metadata in aggregate form. IdP metadata (entity ID, SSO URL, SLO URL, x509 certificate) is configured manually per SAML tenant connection via the admin interface. Each tenant connection stores its own IdP details rather than resolving them from a federation metadata feed.

The platform supports multiple integration protocols. The SP has been tested and verified against the following IdP types:

• Shibboleth
• ADFS
• Okta (as a SAML IdP)
• Microsoft Azure AD / Entra ID (SAML)
• OneLogin (as a SAML IdP)
• Auth0 (as a SAML IdP)
• Any other SAML 2.0 compliant IdP

Managed / OIDC & OAuth2

In addition to SAML, the platform supports the following managed identity providers via OpenID Connect (OIDC) and OAuth 2.0:

• Okta OIDC / OAuth2
• Auth0 OIDC / OAuth2
• Microsoft Azure AD OAuth2
• Microsoft Entra ID OAuth2
• OneLogin OIDC / OAuth2
• Salesforce OAuth2
• Generic OIDC (standard)
• Generic OIDC (Basic Auth) — OIDC with HTTP Basic Auth token endpoint

Customers choose the appropriate protocol (SAML or OIDC/OAuth2) per connection. If your protocol is not listed, we can generally implement it within one business week.

Yes. The application explicitly maps the following OID-format attribute names, in addition to MACE and Microsoft/vendor-specific variants:

Provider-specific attribute names (Microsoft schema URIs, Okta, OneLogin, Auth0, generic short names) are also recognised and mapped automatically.

Required:

• Email address: Must be present in assertion attributes or derivable from NameID (if NameID is a valid email). Login is aborted without a resolvable email.

Optional:

• Display name / full name: Constructed from given + family name if not directly provided.
• Given name (first name): Split from display name if not provided separately.
• Family name (last name): Split from display name if not provided separately.

All four attributes accept the OID, MACE, Microsoft schema, and common shorthand variants listed in the attribute support section.

The SAML NameID is the primary user identifier used to uniquely identify and look up users across sessions.

If the IdP does not include a NameID element in the assertion (e.g. certain Shibboleth deployments that omit it), the application falls back to the mapped email address as the identifier and logs a warning.

Additionally, if the NameID is itself a valid email address (e.g. ADFS deployments that put email in the NameID), it is accepted as both the identifier and the email attribute.

Yes. The NameID is stored as an unbounded string field. There is no length restriction enforced at the application level; identifiers of 32 characters or more (e.g. opaque persistent IDs such as UUIDs or eduPersonTargetedID values) are fully supported.

No strict requirements — NameID format is configurable per tenant.

• Default format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
• Supported formats (configurable per SAML connection): persistent (default), transient, emailAddress, unspecified, X509SubjectName, WindowsDomainQualifiedName
• NameID presence is not required; the SP will fall back to email if NameID is absent.
• NameID encryption is supported but disabled by default; it can be enabled per tenant.

Logout is not supported as Thinkific does not support logout from an SSO interface.

Yes. Each SAML tenant connection exposes a metadata endpoint at:

GET /saml2/{tenant-uuid}/metadata

This endpoint returns a standards-compliant SAML 2.0 SP metadata XML document containing:

• SP Entity ID
• Assertion Consumer Service (ACS) URL (HTTP-POST binding)
• Single Logout Service URL (HTTP-Redirect binding)
• SP x509 certificate (for signature verification/encryption)
• NameID format
• Contact and organisation information

Separate metadata URLs are available for QA and production environments, as each environment has its own tenant UUIDs. These URLs can be provided on request once the environments are provisioned.