All docs

Configure organizational SAML SSO

Use this guide to connect your organization's Shibboleth or other SAML 2.0 identity provider to OASIS.

Before you start

  • An OASIS workspace administrator can manage enterprise SSO connections.
  • An identity provider administrator can register OASIS as a SAML service provider.
  • A test user and a non-production or limited-release identity provider configuration are available.

What is shared and what changes by organization

OASIS uses one standards-based SAML 2.0 service-provider engine for every organization. Signature validation, audience and destination checks, request correlation, time checks, replay prevention, session creation, and audit events do not change from one organization to another.

Each organization receives a separate connection because its identity provider has different endpoints, entity identifiers, certificates, released attributes, MFA context values, and account-provisioning rules. The connection supplies those organization-specific facts without creating a different authentication protocol or weakening the shared validation engine.

Information the two teams exchange

  • OASIS provides its connection-specific entity ID, ACS URL, metadata URL, signing certificate, optional encryption certificate, privacy URL, and technical, security, and administrative contacts.
  • Your identity team provides authoritative IdP metadata, the expected IdP entity ID, released attribute names, a test user, actual AuthnContext values, certificate-rotation plans, and logout behavior.
  • Prefer metadata XML or an approved HTTPS metadata URL over copying endpoints and certificates manually. Both teams must verify entity IDs and URLs exactly.

Identity and access decisions

  • Release one durable account identifier: pairwise-id, subject-id, a persistent NameID, or an explicitly approved immutable institutional identifier. Email addresses and usernames must not be treated as permanent account keys.
  • Release email for communication and account matching. Given name, surname, and display name are optional profile fields.
  • Choose invitation-only access or approved just-in-time provisioning. Configure allowed domains, required active membership, and explicit affiliation or entitlement-to-role mappings.
  • Observe the identity provider's real AuthnContext values before treating upstream authentication as MFA. Unknown or stale assurance must require local step-up when policy requires MFA.

Activation and certification boundary

Saving metadata proves that the two systems are configured; it does not prove interoperability. Keep the connection in test status until an end-to-end login succeeds and the security checks below have been recorded.

A Shibboleth preset means OASIS is configured for expected Shibboleth behavior. It does not mean a specific university or organization is certified. Certification belongs to the exact OASIS connection and identity-provider configuration that were tested together.

Steps

  1. 1Create a separate SAML connection for the organization and select Shibboleth or the appropriate SAML 2.0 preset.
  2. 2Import the identity provider's authoritative metadata and pin the expected entity ID.
  3. 3Configure the durable identifier, email and profile attributes, provisioning policy, role mappings, and MFA assurance policy.
  4. 4Complete the OASIS service name, organization and privacy information, and technical, security, and administrative contacts.
  5. 5Give the identity provider administrator the generated OASIS metadata and ask them to register its exact entity ID and POST ACS endpoint.
  6. 6Ask the identity provider administrator to release the agreed durable identifier and attributes to only this OASIS service provider.
  7. 7Start an SP-initiated login with a test user and confirm the redacted event records the expected issuer, subject type, attributes, AuthnContext, and SessionIndex.
  8. 8Test signed requests if required, signed responses and assertions, encrypted assertions if enabled, certificate rollover, expired responses, incorrect issuer/audience/destination, replay attempts, disabled users, provisioning, and logout.
  9. 9Record the interoperability results, obtain approval from both teams, activate the connection, and retain a tested administrative break-glass sign-in path.

Result

The organization can start sign-in from OASIS and reach the correct workspace through its own identity provider, while other organizations remain isolated on their own connections.

If it does not work

  • If metadata imports but login fails, compare the exact entity ID, ACS URL, binding, issuer, audience, destination, signing policy, and current certificates on both sides.
  • If the user is recognized but denied, verify the durable identifier, released email, invitation or JIT policy, active membership, allowed domain, and role mappings.
  • If MFA is not accepted, record the actual AuthnContext value and authentication time before changing the assurance policy.
  • Do not activate the connection or claim organization certification based only on automated tests or successful metadata import.
  • Contact support if the issue continues.