SAML SSO Implementation Checklist Builder
Plan a secure SAML SSO rollout with metadata, user mapping, multi-tenant settings, tests, troubleshooting, and enterprise launch steps.
Prompt Template
You are a senior identity and application security engineer. Create an implementation checklist for adding SAML SSO to my product. **Application stack:** [language/framework/auth library] **Current auth model:** [email/password, OAuth, magic link, existing tenants] **Target IdPs:** [Okta, Microsoft Entra ID, Google Workspace, OneLogin, etc.] **Tenant model:** [single tenant / multi-tenant / enterprise workspaces] **User provisioning needs:** [manual invite, SCIM later, just-in-time provisioning] **Required attributes:** [email, name, groups, role, tenant ID] **Security/compliance requirements:** [SOC 2, HIPAA, audit logs, MFA policy, signed assertions] **Deployment timeline:** [pilot date and launch date] Build a checklist covering: 1. **Architecture decisions** — SP-initiated vs IdP-initiated, tenant discovery, account linking 2. **SAML metadata requirements** — ACS URL, Entity ID, certificate rotation, NameID, attributes 3. **Security controls** — signed assertions, encrypted assertions if needed, replay prevention, clock skew, audience validation 4. **Data model changes** — identity provider records, domains, certificates, user mappings, audit events 5. **User experience** — login buttons, domain routing, fallback auth, error pages, admin setup flow 6. **Testing plan** — unit, integration, IdP sandbox, negative tests, certificate rotation rehearsal 7. **Operational runbook** — troubleshooting common errors, support diagnostics, rollback plan 8. **Rollout plan** — internal test, pilot customer, general availability, documentation Include implementation gotchas for multi-tenant SaaS products and clear acceptance criteria for launch.
Example Output
SAML SSO Checklist for B2B SaaS
Architecture Decisions
- Use **SP-initiated SSO** as the default flow.
- Resolve tenant by verified email domain before redirecting to the IdP.
- Allow one tenant to configure multiple IdPs only if enterprise plans require it.
- Keep password login available for tenant admins until SSO is verified.
Required Metadata
| Field | Example | Notes |
|---|---|---|
| ACS URL | https://app.example.com/auth/saml/callback/:tenantId | Tenant-scoped to prevent cross-tenant assertion reuse |
| Entity ID | https://app.example.com/saml/metadata | Stable identifier |
| NameID | emailAddress | Normalize lower-case before matching |
Negative Tests
- Assertion audience does not match → reject
- Expired assertion → reject with support-safe error
- Unsigned response when signing is required → reject
- Email belongs to another tenant → reject and audit
Launch Acceptance Criteria
- 3 successful login paths across Okta and Entra ID
- Audit log records setup, login success, login failure, cert update
- Admin can download SP metadata and rotate IdP certificate without code deploy
Tips for Best Results
- 💡Include your tenant model; SAML bugs are often cross-tenant routing bugs, not protocol bugs.
- 💡Ask the model to include negative tests, not just happy-path configuration steps.
- 💡Never paste private keys or production certificates into an AI tool.
- 💡Plan certificate rotation before launch; future-you will send flowers.
Related Prompts
Code Review Assistant
Get a thorough, senior-level code review with actionable feedback on quality, security, performance, and best practices.
Debugging Detective
Systematically debug errors and unexpected behavior with root cause analysis and fix suggestions.
Code Refactoring Advisor
Transform messy, complex code into clean, maintainable, well-structured code with clear explanations.