Single Sign-On (SSO) Technical

1. Feature Purpose (System-Level)

Single Sign-On (SSO) enables external users to authenticate to the Event Cadence platform using their organization's existing identity provider (IdP) rather than managing separate credentials. The system implements SAML 2.0 protocol to establish a trust relationship between the customer's IdP and Event Cadence services. Once configured, users are redirected to their organization's authentication portal during login and returned to Event Cadence with authenticated access.
The feature supports multi-tenant SSO configurations, allowing different organizations to maintain separate SSO integrations within the same platform instance. Access control operates at two levels: the IdP determines who can authenticate, while Event Cadence determines who has an active account.

2. High-Level Flow (System Behavior)

When a user attempts to log in with an SSO-enabled email domain, the system initiates a SAML authentication request and redirects the user to their organization's IdP. The IdP validates the user's credentials and generates a SAML response containing the user's email address and authentication assertions. This response is sent to the Assertion Consumer Service URL ( https://account.eventcadence.com/authsaml/signonendpoint ), where the authentication service validates the SAML signature and assertions.
The system extracts the email address from the SAML response and queries the user database. If a matching user account exists, access is granted. After successful authentication, the user is redirected to the event platform with an authenticated session.
On mobile platforms, Android uses Chrome Custom Tabs for the SSO login flow, while iOS implements SSO through native web views.

3. System Diagrams

System Architecture Diagram

flowchart LR
User[User] --> LoginPage[Login Page Web/Mobile]
LoginPage --> SSOService[SAML SSO Service]
SSOService --> IdP[Identity Provider Okta/Azure/Google]
IdP --> SSOService
SSOService --> AuthService[Authentication Service]
AuthService --> UserDB[User Account Database]
UserDB --> AuthService
AuthService --> EventAccess[Event Access Granted]
CadenceAdmin[CadenceAdmin] --> SSOConfig[SSO Configuration]
SSOConfig --> SSOService


Processing Flow

sequenceDiagram
participant User
participant LoginPage
participant SSOService
participant IdP
participant AuthService
participant UserDB
participant EventPlatform

User->>LoginPage: Enter email with SSO domain
LoginPage->>SSOService: Initiate SSO login
SSOService->>IdP: Redirect to IdP with SAML request
IdP->>User: Present login page
User->>IdP: Authenticate with credentials
IdP->>IdP: Validate credentials
IdP->>SSOService: Send SAML response to ACS URL
SSOService->>SSOService: Validate SAML signature and assertions
SSOService->>AuthService: Extract email from SAML response
AuthService->>UserDB: Query user by email
UserDB->>AuthService: Return user account or null
alt User exists
AuthService->>EventPlatform: Grant access with user session
EventPlatform->>User: Redirect to event home
else User not found
AuthService->>User: Access denied - no matching account
end


4. Key Components and Data Objects

Authentication Components

  • SAML SSO Service: Validates SAML responses, manages metadata exchange, and enforces trust relationships
  • Authentication Service: Verifies user credentials and manages SSO sessions with support for specific domains
  • User Account Database: Stores user records matched by email address

Configuration Data Objects

  • Entity ID: Unique identifier for the Event Cadence SAML configuration
  • Reply URL (Assertion Consumer Service URL): Endpoint for SAML responses at  https://account.eventcadence.com/authsaml/signonendpoint 
  • Logout URL: Optional endpoint for Single Logout at  https://account.eventcadence.com/authsaml/logoutendpoint 
  • Metadata URL: Organization-specific metadata endpoint with format  https://account.eventcadence.com/authsaml/info/[org-id] 
  • IdP Metadata XML: Contains Identity Provider Single Sign-On URL, Identity Provider Issuer, and signing certificates

SAML Configuration Settings

  • Name ID Format: EmailAddress
  • Name ID Attribute: Primary user email
  • Responses Signed: Yes
  • Assertions Signed: Yes
  • Authentication Context: PasswordProtectedTransport (default)

5. Dependencies and Constraints

External Dependencies

  • Identity Providers: Okta, Azure AD, Google Workspace, OneLogin, and other SAML 2.0 compliant IdPs
  • SAML 2.0 Protocol: Required for authentication exchange
  • SSL/TLS Certificates: IdP signing certificates must be current and valid
  • Metadata Exchange: Bidirectional metadata sharing between Event Cadence and customer IdP

System Constraints

  • Users without a corresponding Event Cadence account cannot log in via SSO unless the IdP is configured to auto-create accounts
  • User accounts are matched by email address; email mismatches between IdP and Event Cadence can prevent authentication
  • When an SSO user's email changes, the IdP must update the email attribute, or the user's third-party-id must be set to the old email to maintain account continuity

Configuration Options

  • Organizations can disable email login completely and enforce SSO-only authentication
  • Available login options: Email Magic Link or Email with Password (default), Email with Password only, or SSO only

Provisioning Workflow

  • Event Cadence supplies a unique metadata page for the customer's account that contains the necessary values and metadata.
  • IT team applies the metadata to your IdP provided by Event Cadence
  • IT team provides your IdP metadata XML or metadata URL to Event Cadence
  • Event Cadence completes setup, typically within 1 business day


Ongoing Maintenance Requirements

The only maintenance requirement mentioned is related to certificate rotation:
  • Certificate rotation in the IdP requires updated metadata to be provided to Event Cadence to maintain the trust relationship
  • SSL/TLS Certificates: IdP signing certificates must be current and valid
This is typically an as-needed activity that occurs when the Identity Provider's signing certificates expire (usually annually or every few years, depending on the IdP's certificate lifecycle).