# 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:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_