SSO Provider Overview
Passport acts as the enterprise Identity Provider (IdP) — configure it once and any external application can delegate authentication to BizFirstGO credentials.
What Is an SSO Provider?
When Passport operates as an SSO Provider, it becomes the authoritative identity source for external applications. Instead of each application maintaining its own user database, they register as Relying Parties (Service Providers) and defer login to Passport. Users authenticate once and access all connected applications without re-entering credentials.
This model is sometimes called federated identity or outbound federation — Passport issues signed assertions that downstream applications trust, rather than accepting credentials directly.
Supported Protocols
SAML 2.0
Industry-standard XML-based SSO protocol. Broad enterprise compatibility — works with Salesforce, ServiceNow, Jira, Confluence, Zendesk, and hundreds of SaaS applications out of the box.
OIDC / OAuth 2.0
Modern JSON/JWT-based identity protocol. Preferred for custom applications, mobile apps, and Single-Page Applications. Supports PKCE for public clients and client credentials for service-to-service.
Discourse Connect
Lightweight SSO protocol for community platforms. Enables Discourse forums and similar platforms to use Passport credentials without a full SAML/OIDC stack.
Trust Model
Every external application must be registered in Passport before SSO can begin. Registration establishes the trust relationship and defines what the application is allowed to request.
| Trust Element | SAML | OIDC |
|---|---|---|
| Application identifier | Entity ID (URI) | Client ID |
| Assertion destination | ACS URL (assertion consumer service) | Redirect URI |
| Shared secret | X.509 signing certificate | Client secret (or JWKS for public) |
| Permitted claims/attributes | Attribute statement list | Scope + claims list |
| Session policy | AuthnContext + SessionIndex | id_token + session cookie |
Architecture Overview
The SSO Provider subsystem is built on three collaborating layers:
Protocol Endpoint
GET /sso/provider/{consumerKey} — receives the initial SSO challenge from the external application. Validates the request format and routes it to the orchestrator.
OutboundSsoOrchestrator
Core logic layer. Validates the consumer registration, parses the challenge using the appropriate protocol adapter, checks user authentication and authorization, and builds the SSO principal.
Protocol Adapters
Protocol-specific serialization. The SAML2Adapter builds a signed XML assertion; the OIDCAdapter issues a JWT id_token. New protocols are added here without touching core logic.
Assertion Delivery
The signed assertion is delivered back to the application. SAML via HTTP POST to the ACS URL; OIDC via authorization code redirect followed by token endpoint exchange.
Audit Event
Every SSO event — initiation, success, failure — is recorded in the audit log with timestamp, user, consumer, and protocol details.
Key Endpoints
| Endpoint | Protocol | Description |
|---|---|---|
GET /passport/saml/metadata | SAML | Publish this XML metadata URL to relying parties — contains entity ID, ACS URL, and signing certificate |
GET /passport/.well-known/openid-configuration | OIDC | Standard OIDC discovery document — authorization endpoint, token endpoint, JWKS URI, supported scopes |
GET /passport/.well-known/jwks.json | OIDC / SAML | Public signing keys — consuming applications use this to verify token signatures |
GET /sso/provider/{consumerKey} | All | Initiate SSO — consumer sends challenge parameters here |
GET /sso/provider/{consumerKey}/resume | All | Resume after user authentication — completes the assertion flow |
POST /passport/saml/slo | SAML | Single Logout — receive SLO request from a relying party |
Multi-Tenant Isolation
Passport is fully multi-tenant. Each consumer registration is scoped to a tenant. A user from tenant-A cannot authenticate to a consumer registered under tenant-B. Tenant isolation is enforced at the OutboundSsoOrchestrator level before any assertion is generated.
Start with SAML 2.0 Provider if you are connecting an enterprise application that requires SAML, or OIDC Provider for modern web or mobile applications. Then configure Application Trust to register your relying party.