Key Takeaways:SAML 2.0 Configuration for E-Signature Platforms · Okta vs. Azure AD Integration Differences · SCIM Provisioning for User Lifecycle · Session Management and MFA Enforcement · Audit Trail Compliance with SSO
TL;DR: Enterprise e-signature deployments fail when they exist outside the organization's identity infrastructure. This guide covers the technical details of integrating e-signature platforms with Okta, Azure AD (Entra ID), and generic SAML 2.0 identity providers — including SCIM user provisioning, session management, MFA enforcement, and the audit trail implications of centralized authentication.
When an enterprise deploys an e-signature platform without SSO integration, it creates a shadow identity silo: separate passwords, separate MFA, separate user provisioning, and separate audit logs. Every shadow identity silo increases attack surface, creates compliance gaps, and generates IT support tickets from users who can't remember yet another password.
SSO integration solves this by making the e-signature platform a relying party in the organization's existing identity ecosystem. Users authenticate once through their corporate identity provider and access the e-signature platform seamlessly. When an employee leaves, their SSO access is revoked centrally, and their e-signature access terminates automatically.
But "just enable SSO" undersells the engineering involved. SAML assertion mapping, SCIM attribute synchronization, session timeout alignment, MFA step-up requirements, and audit trail correlation all need careful configuration. This guide walks through each of these for the three most common enterprise identity providers.
SAML 2.0 (Security Assertion Markup Language) remains the dominant federation protocol for enterprise SSO. Understanding the SAML flow and its configuration points is essential for a clean integration.
The SP-initiated SAML flow for e-signatures:
User navigates to the e-signature platform (Service Provider / SP)
SP detects no active session and generates a SAML AuthnRequest
SP redirects user to the Identity Provider (IdP) login page
User authenticates at the IdP (password + MFA)
IdP generates a signed SAML Response containing assertions about the user
IdP POST-redirects the user back to the SP's Assertion Consumer Service (ACS) URL
SP validates the SAML Response signature, extracts assertions, and creates a session
Critical SAML configuration parameters:
Entity ID — unique identifier for the SP; must match exactly between IdP configuration and SP metadata
ACS URL — the endpoint where the IdP sends the SAML Response; must be HTTPS and must match the registered value exactly
NameID format — use urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress for e-signature platforms since email is the universal user identifier
Attribute mapping — map IdP attributes to SP user profile fields (displayName, department, role)
Signing certificate — the IdP's X.509 certificate used to sign SAML assertions; must be rotated before expiration to avoid authentication failures
RelayState — preserves the user's intended destination URL through the SSO flow; critical for deep-linking to specific documents or envelopes
Common SAML pitfalls:
Clock skew — SAML assertions include NotBefore/NotOnOrAfter timestamps; if the SP and IdP clocks differ by more than the allowed tolerance (typically 5 minutes), authentication silently fails
Certificate rotation — when the IdP rotates its signing certificate, the SP must be updated before the old certificate expires; plan for dual-certificate support during rotation windows
NameID mismatch — if users were provisioned in the e-signature platform with a different email domain than the IdP sends in NameID, SSO will create duplicate accounts instead of linking to existing ones
Okta vs. Azure AD (Entra ID): Platform-Specific Guidance#
While both Okta and Azure AD support SAML 2.0 and SCIM, their implementation details and admin experiences differ meaningfully.
Okta integration specifics:
App catalog — Okta's Integration Network (OIN) provides pre-built SAML configurations for many e-signature platforms, reducing setup to metadata exchange
Attribute mapping — Okta uses an expression language for attribute transformations (e.g., String.substringBefore(user.email, "@") to extract username)
Group push — Okta can push group memberships to the SP via SCIM, enabling role-based access control synchronized from the directory
Inline hooks — Okta's inline hooks can modify SAML assertions in real-time, enabling custom logic (e.g., adding a cost-center attribute from an external HR system)
Session duration — configure Okta's global session policy and the application-specific sign-on policy independently; the more restrictive policy wins
Azure AD (Entra ID) integration specifics:
Enterprise Application registration — Azure AD uses the Enterprise Applications blade for SAML SP registration; the App Registration blade is for OAuth/OIDC and should not be used for SAML
Claims mapping — Azure AD uses claims transformation rules; complex transformations may require custom claims policies (JSON-based)
Conditional Access — Azure AD's Conditional Access policies can enforce location-based, device-compliance, and risk-based MFA requirements per application; use this to require step-up MFA for e-signature access from unmanaged devices
SCIM provisioning — Azure AD's provisioning service supports SCIM 2.0 with automatic user creation, updates, and deactivation; configure attribute mappings in the Provisioning blade
Token signing — Azure AD auto-generates a self-signed certificate; for production, upload a CA-signed certificate for better certificate management
Choosing between SAML and OIDC:
Azure AD also supports OpenID Connect (OIDC), which is simpler to implement and uses JWTs instead of XML assertions. If the e-signature platform supports both protocols, OIDC is generally preferred for new integrations due to simpler debugging and better mobile support. Okta supports both as well, but SAML remains more common in enterprise e-signature deployments due to legacy compatibility.
SSO handles authentication, but SCIM (System for Cross-domain Identity Management) handles the equally important question of who exists in the system and what can they do.
Why SCIM matters for e-signature platforms:
Without SCIM, user provisioning is manual. An admin must create accounts in the e-signature platform separately from the directory. When employees leave, their directory account is disabled but their e-signature account persists — creating a security gap where former employees can still access sensitive documents.
SCIM automates the full user lifecycle:
Provisioning — when a user is assigned to the e-signature application in the IdP, SCIM automatically creates their account with correct attributes
Updates — when a user's department, title, or role changes in the directory, SCIM propagates the change to the e-signature platform
Deprovisioning — when a user is removed from the application assignment or their directory account is disabled, SCIM deactivates their e-signature account
SCIM attribute mapping for e-signatures:
Directory Attribute
SCIM Attribute
E-Signature Field
Notes
mail
emails[primary]
Email / Username
Primary identifier
displayName
displayName
Display Name
Appears on signature blocks
department
urn:custom:department
Team / Group
For routing and permissions
title
title
Role Display
Optional
manager
urn:custom:manager
Approval Chain
For workflow routing
SCIM implementation considerations:
Initial sync — the first SCIM sync can be large (thousands of users); the e-signature platform must handle bulk creation without timeouts
Conflict resolution — if a user already exists in the e-signature platform (created before SCIM was enabled), the SCIM integration must match on email and link rather than create duplicates
Soft delete vs. hard delete — SCIM deprovisioning should deactivate, not delete, user accounts; deleted accounts lose audit trail associations, which creates compliance problems
Rate limiting — SCIM clients (Okta, Azure AD) must respect the e-signature platform's API rate limits; configure provisioning intervals accordingly
SSO integration isn't just an IT convenience — it has direct implications for the legal validity of electronic signatures and regulatory compliance.
Session management alignment:
The e-signature platform's session timeout must align with your SSO session policy. If the IdP session expires after 8 hours but the e-signature platform maintains a 24-hour session, users remain authenticated in the e-signature platform after their corporate session ends — defeating the purpose of centralized session management.
Configure the e-signature platform to:
Check IdP session validity on each critical action (document signing, template creation)
Implement re-authentication for high-risk operations regardless of session state
Honor IdP-initiated single logout (SLO) to terminate all sessions when a user logs out centrally
MFA enforcement for signing events:
Not all e-signature actions require the same level of assurance. Configure your identity provider to require step-up MFA for signing events:
Standard authentication (password + push notification) for viewing documents and managing templates
Step-up MFA (hardware key or biometric) for signing high-value contracts, approving financial documents, or accessing audit logs
Re-authentication for any signing event initiated more than 30 minutes after last authentication
Audit trail correlation:
When SSO is properly integrated, every e-signature audit trail entry includes the IdP session identifier, linking the signing event to the corporate authentication event. This correlation is critical for:
Regulatory audits — demonstrating that the signer was authenticated through the organization's approved identity infrastructure
Dispute resolution — proving that the signature was made by an authenticated corporate user, not someone with stolen credentials
Compliance reporting — generating unified access reports across all enterprise applications, including e-signature activity
ZiaSign supports SAML 2.0 and SCIM 2.0 integration with Okta, Azure AD (Entra ID), and any standards-compliant identity provider — with built-in session management alignment, step-up MFA hooks, and correlated audit trails that satisfy SOC 2, HIPAA, and FedRAMP requirements.