SSO Application Onboarding Checklist

Purpose: Collect the technical, security, and business requirements needed to onboard a new or existing application to Enterprise Single Sign-On (SSO).

Instructions: Complete all applicable fields. Mark non-applicable items as N/A and document exceptions with an owner and target resolution date. Do not share client secrets or private keys through this questionnaire.

---

1. Governance and Application Overview

• Application name
• Application description and business purpose
• Application documentation / vendor integration guide URL
• Application owner name and contact information
• Technical owner / engineering contact
• Vendor name and technical point of contact
• Vendor support email / phone / support portal
• Is this a new application or an existing application?
• If existing, describe the current authentication and login process.
• Has the application been approved by the Architecture Review Board (ARB)?
• Architecture review reference / approval date
• Is this a regulated or compliance-sensitive application (SOX, PCI DSS, HIPAA, etc.)?
• Application data classification (Public, Internal, Confidential, Restricted)
• User population / estimated number of users
• User types: Employees, Contractors, Partners, Customers, Service Accounts
• Deployment scope: Property-specific, Instance-specific, Regional, or Global
• Number of application instances / tenants
• Number of environments: DEV, Sandbox, QA, UAT, Non-Production, Production
• Application hosting model: SaaS, On-Premises, Cloud, Hybrid
• Business criticality and availability requirements
• Target SSO onboarding date
• Dependencies or upstream/downstream integrations

2. SSO Protocol and Integration Requirements

• Requested protocol: SAML 2.0 / OpenID Connect (OIDC)
• Is the protocol supported natively by the application?
• If neither is supported, identify available integration options.
• Does the application support OAuth 2.0 authorization for APIs?
• Does the application support modern authentication libraries and security controls?
• Is an identity broker, access gateway, or reverse proxy required?
• Identity Provider (IdP) / enterprise identity platform
• Environment-specific configuration requirements
• Required network connectivity, firewall rules, DNS, and certificates

3. SAML 2.0 Service Provider (SP) Metadata

Preferred: Provide a vendor-hosted SP metadata URL. Alternatively, attach the SP metadata XML file through an approved secure channel.

• SP metadata URL
• SP metadata XML attachment, if no URL is available
• Entity ID / Audience URI
• Assertion Consumer Service (ACS) URL(s)
• SP-initiated SSO URL
• Single Logout (SLO) URL, if supported
• NameID format required
• NameID value / user identifier
• SAML binding requirements (HTTP-Redirect / HTTP-POST)
• Is signed AuthnRequest required?
• Is encrypted assertion support required?
• Required SAML response and assertion signing behavior:
  • Sign SAML response
  • Sign SAML assertion
  • Sign both
• Signing certificate details and expiration date
• Certificate rotation requirements
• Assertion validity / clock-skew requirements
• Supported SAML attributes and claim mappings
• Multiple ACS URLs, tenants, or property-specific endpoints
• Metadata refresh and certificate rollover procedure

4. OpenID Connect (OIDC) Configuration

• OIDC issuer / discovery URL requirements
• Client type: Confidential / Public
• Application redirect URI(s) — exact URLs for each environment
• Post-logout redirect URI(s)
• Client ID
• Client authentication method (e.g., client secret or private-key JWT, if supported)
• Client secret provisioned through an approved secrets manager, if applicable
• PKCE support (required for public clients and recommended as a baseline for all clients)
• Authorization Code Flow support
• Required scopes: openid, profile, email, and other justified scopes
• Required ID token claims
• Required access token claims, if applicable
• Additional claims / custom attributes
• Token validation and issuer/audience requirements
• Access token lifetime requirements
• Refresh token support and rotation / replay detection requirements, where applicable
• JWKS endpoint and signing-key rotation support
• Back-channel logout or session termination support, if applicable
• API resource audience and authorization requirements, if the application calls APIs

Security note: Do not record actual client secret values in this checklist, email, or ordinary tickets. Store secrets only in the approved secrets manager.

5. Authentication Context and Policy Compatibility

• Does the application send a SAML AuthnRequest with a specific authentication context (RequestedAuthnContext / AuthnContextClassRef)?
• Does the application require a specific authentication method or assurance level?
• Does the application send ForceAuthn=true?
• Does the application require MFA or step-up authentication?
• Does the application support the enterprise IdP's authentication policies?
• Are password-only or legacy authentication methods explicitly required?
• Has the requested authentication context been tested against the IdP policy?

If the application's requested authentication context is incompatible with enterprise policy:

• Confirm the exact request and error with the application vendor.
• Ask whether the requested context can be removed or made configurable.
• Confirm that the IdP can enforce the required MFA and assurance level independently.
• Test the resulting login flow before production rollout.
• Document and approve any exception.

Important: Do not automatically remove authentication-context restrictions without assessing their security intent. The IdP's policy must still satisfy the application's required assurance level. The vendor should confirm the intended behavior and supported configuration.

6. Claims, Attributes, Groups, and Roles

• Required user identifier / NameID / subject claim
• Email address
• Employee ID / workforce identifier
• First name and last name
• Department / cost center / location / property
• Manager or organizational attributes, if required
• Groups / application roles / entitlements
• Required claim names, formats, and value mappings
• Group overage or large group-membership handling
• Role mapping and authorization model
• Default role for new users
• Least-privilege access and segregation-of-duties requirements
• User provisioning approach: Manual / JIT / SCIM / IAM workflow / API
• User deprovisioning and access revocation process
• Handling of disabled, terminated, or transferred users
• Local application accounts and authentication dependencies
• Will local login be disabled after successful SSO migration?
• If local login must remain, document the business justification and restrictions.
• Is a documented break-glass access process available?
• Break-glass owner, monitoring, and periodic review requirements

7. Login Initiation and Authentication Journey

• SP-initiated SSO supported
• IdP-initiated SSO supported, if needed
• Required login initiation method
• Default landing page / application URL
• Deep-link / RelayState behavior
• MFA and Conditional Access requirements
• Step-up authentication for privileged or sensitive operations
• Multiple identity providers or user populations
• Session behavior across multiple tabs and devices
• Error handling for unauthorized or unassigned users
• Account linking and duplicate-user handling
• Login failure messaging and troubleshooting contacts

8. User Session and Logout Behavior

• Application session lifetime / absolute timeout
• Idle session timeout
• Session renewal behavior
• Logout URL and redirect requirements
• SP-initiated logout support
• IdP-initiated logout support, if required
• SAML Single Logout (SLO) support, if applicable
• OIDC RP-initiated logout / supported session termination mechanisms, if applicable
• Behavior when the IdP session expires
• Behavior when the application session expires
• Token revocation and refresh token invalidation behavior
• Session termination after account disablement or termination
• Mobile application support: Yes / No
• Mobile platform: iOS / Android / Both
• Native mobile OIDC support / system browser support
• Mobile deep links and redirect URI requirements
• Shared-device / kiosk session requirements, if applicable

Note: IdP logout does not automatically terminate every downstream application session. Validate the actual logout and revocation behavior with the application.

9. Provisioning and Identity Lifecycle

• Authoritative identity source
• User provisioning method
• SCIM 2.0 support, if available
• API-based provisioning support
• Joiner / Mover / Leaver (JML) workflow requirements
• Access request and approval workflow
• Role assignment and entitlement mapping
• Deprovisioning SLA
• Reconciliation / access review requirements
• Orphaned-account detection
• Service accounts and non-human identities
• Failure handling, retry, and reconciliation process
• Audit evidence and compliance reporting

10. Security, Privacy, and Compliance

• MFA / Conditional Access requirements approved
• Encryption in transit enforced
• Redirect URI / ACS URL validation completed
• SAML signature and assertion validation verified
• OAuth/OIDC issuer, audience, nonce, state, and signature validation verified where applicable
• PKCE and authorization-code protections tested
• Token storage and browser exposure risks assessed
• Certificate and signing-key lifecycle documented
• Secrets stored and rotated securely
• Security logging and monitoring enabled
• Sensitive claims minimized
• Access control and authorization tested
• Compliance and data-retention requirements reviewed
• Threat model / security review completed where required
• Security exceptions documented, approved, and time-bound

11. Testing and Validation

• DEV / Non-Production configuration completed
• Successful SP-initiated login tested
• IdP-initiated login tested, if supported and required
• MFA / Conditional Access tested
• Claims and attributes validated
• Role and group mapping validated
• Unauthorized-user behavior tested
• Disabled / terminated-user behavior tested
• Session timeout tested
• Logout and session termination tested
• Certificate / key rollover tested or validated
• Error handling and troubleshooting tested
• Mobile login tested, if applicable
• API authorization tested, if applicable
• Regression and business-user acceptance testing completed
• Test evidence attached to the approved change record
• Application owner and IAM sign-off obtained

12. Production Rollout and Change Management

• Production configuration reviewed and approved
• Rollout scope: Property-specific / Instance-specific / Regional / Global
• Pilot users / pilot property identified
• Phased rollout plan documented
• Change request approved
• Application owner and support team notified
• End-user communication prepared
• Support runbook and escalation path documented
• Monitoring and alerting enabled
• Rollback plan tested or validated
• Legacy authentication retirement date defined
• Post-production validation completed
• Business and IAM acceptance recorded

13. Operational Readiness and Support

• Application support team and operating hours
• IAM support ownership
• Vendor escalation process
• Troubleshooting guide / knowledge article
• Monitoring dashboards and alerts
• Certificate and secret expiry alerts
• SSO failure / authentication error monitoring
• Incident response and recovery procedures
• Access review and reconciliation ownership
• Periodic configuration review scheduled
• Application owner and technical contacts validated

14. Final Sign-Off

• Application owner approval
• IAM engineering approval
• Security approval, where required
• Architecture approval, where required
• Compliance / control-owner approval, where required
• Change management approval
• Production readiness confirmed
• Documentation and support handover completed

Onboarding status: Not Started / In Progress / Blocked / Ready for Production / Completed

Outstanding actions / risks:

Action / Risk	Owner	Due Date	Status

Final approval date: ____________________

Production go-live date: ____________________