implementing-saml-sso-with-okta skill (Anthropic-Cybersecurity-Skills)

From Public Agent Wiki

What it does. Implement SAML 2.0 Single Sign-On using Okta as the Identity Provider, Part of mukul975/Anthropic-Cybersecurity-Skills (817 security skills) (mukul975/Anthropic-Cybersecurity-Skills).
Upstream mukul975/Anthropic-Cybersecurity-Skills
Skill file skills/implementing-saml-sso-with-okta/SKILL.md
License Apache-2.0 (skill folder LICENSE)
Author mukul975
Fetched 2026-09-10

Install

  • npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill implementing-saml-sso-with-okta, or copy the skill folder into ~/.claude/skills/implementing-saml-sso-with-okta/.
  • Raw file: curl -sL https://raw.githubusercontent.com/mukul975/Anthropic-Cybersecurity-Skills/HEAD/skills/implementing-saml-sso-with-okta/SKILL.md

SKILL.md (verbatim)

name: implementing-saml-sso-with-okta
description: Implement SAML 2.0 Single Sign-On using Okta as the Identity Provider,
  covering SP-initiated and IdP-initiated flows, attribute mapping, certificate management,
  SHA-256 signature enforcement, and Single Logout. Use when configuring Okta SAML SSO
  for an application, hardening SAML certificate rotation and signing, or testing and
  troubleshooting SAML assertion flows with a tracer tool.
domain: cybersecurity
subdomain: identity-access-management
tags:
- iam
- identity
- access-control
- authentication
- saml
- sso
- okta
version: '1.0'
author: mahipal
license: Apache-2.0
nist_csf:
- PR.AA-01
- PR.AA-02
- PR.AA-05
- PR.AA-06
mitre_attack:
- T1078
- T1110
- T1556
- T1098
- T1553
mitre_f3:
  version: '1.1'
  tactics:
  - initial-access
  - positioning
  - resource-development
  techniques:
  - id: T1586
    name: Compromise Accounts
    tactic: resource-development
    source: attack
  - id: T1539
    name: Steal Web Session Cookie
    tactic: positioning
    source: attack
  - id: F1004
    name: Access with Stolen Session Cookie
    tactic: initial-access
    source: f3
  - id: T1550.001
    name: 'Use Alternate Authentication Material: Application Access Token'
    tactic: initial-access
    source: attack
  - id: F1006.003
    name: 'Account Takeover: Password Reset'
    tactic: initial-access
    source: f3

Implementing SAML SSO with Okta

Overview

Implement SAML 2.0 Single Sign-On (SSO) using Okta as the Identity Provider (IdP). This skill covers end-to-end configuration of SAML authentication flows, attribute mapping, certificate management, and security hardening for enterprise SSO deployments.

When to Use

  • When deploying or configuring implementing saml sso with okta capabilities in your environment
  • When establishing security controls aligned to compliance requirements
  • When building or improving security architecture for this domain
  • When conducting security assessments that require this implementation

Prerequisites

  • Familiarity with identity access management concepts and tools
  • Access to a test or lab environment for safe execution
  • Python 3.8+ with required dependencies installed
  • Appropriate authorization for any testing activities

Objectives

  • Configure Okta as a SAML 2.0 Identity Provider
  • Implement SP-initiated and IdP-initiated SSO flows
  • Map SAML attributes and configure assertion encryption
  • Enforce SHA-256 signatures and secure certificate rotation
  • Test SSO flows with SAML tracer tools
  • Implement Single Logout (SLO) handling

Key Concepts

SAML 2.0 Authentication Flow

  1. SP-Initiated Flow: User accesses Service Provider -> SP generates AuthnRequest -> Redirect to Okta IdP -> User authenticates -> Okta sends SAML Response -> SP validates assertion -> Access granted
  2. IdP-Initiated Flow: User authenticates at Okta -> Selects application -> Okta sends unsolicited SAML Response -> SP validates -> Access granted

Critical Security Requirements

  • SHA-256 Signatures: All SAML assertions must use SHA-256 (not SHA-1) for digital signatures
  • Assertion Encryption: Encrypt SAML assertions using AES-256 to protect attribute values in transit
  • Audience Restriction: Configure audience URI to prevent assertion replay across different SPs
  • NotBefore/NotOnOrAfter: Enforce time validity windows to prevent stale assertion usage
  • InResponseTo Validation: Verify assertion corresponds to the original AuthnRequest

Okta Application Configuration

  • Single Sign-On URL: The ACS (Assertion Consumer Service) endpoint on the SP
  • Audience URI (SP Entity ID): Unique identifier for the SP
  • Name ID Format: EmailAddress, Persistent, or Transient
  • Attribute Statements: Map Okta user profile attributes to SAML assertion attributes
  • Group Attribute Statements: Include group membership for RBAC

Workflow

Step 1: Create SAML Application in Okta

  1. Navigate to Applications > Create App Integration
  2. Select SAML 2.0 as the sign-on method
  3. Configure General Settings (App Name, Logo)
  4. Set Single Sign-On URL (ACS URL)
  5. Set Audience URI (SP Entity ID)
  6. Configure Name ID Format and Application Username

Step 2: Configure Attribute Mapping

  • Map user.email to email attribute
  • Map user.firstName and user.lastName to name attributes
  • Add group attribute statements for role-based access
  • Configure attribute value formats (Basic, URI Reference, Unspecified)

Step 3: Download and Install IdP Metadata

  • Download Okta IdP metadata XML
  • Extract IdP SSO URL, IdP Entity ID, and X.509 certificate
  • Install certificate on SP side for signature validation
  • Configure SP metadata with ACS URL and Entity ID

Step 4: Implement SP-Side SAML Processing

  • Parse and validate SAML Response XML
  • Verify digital signature using IdP certificate
  • Check audience restriction, time conditions, and InResponseTo
  • Extract authenticated user identity and attributes
  • Create application session based on assertion data

Step 5: Security Hardening

  • Enforce SHA-256 for all signature operations
  • Enable assertion encryption with AES-256-CBC
  • Configure session timeout and re-authentication policies
  • Implement SAML artifact binding for sensitive deployments
  • Set up certificate rotation procedure before expiry

Step 6: Testing and Validation

  • Use SAML Tracer browser extension for debugging
  • Validate SP-initiated and IdP-initiated flows
  • Test with multiple user accounts and group memberships
  • Verify SLO functionality
  • Test certificate rotation without downtime

Security Controls

Control NIST 800-53 Description
Authentication IA-2 Multi-factor authentication through Okta
Session Management SC-23 SAML session lifetime controls
Audit Logging AU-3 Log all SSO authentication events
Certificate Management SC-17 PKI certificate lifecycle management
Access Enforcement AC-3 SAML attribute-based access control

Common Pitfalls

  • Using SHA-1 instead of SHA-256 for SAML signatures
  • Not validating InResponseTo in SAML responses (replay attacks)
  • Clock skew between IdP and SP causing assertion rejection
  • Failing to restrict audience URI allowing assertion forwarding
  • Not implementing certificate rotation before expiry causes outage

Verification

  • SAML SSO login completes successfully via SP-initiated flow
  • IdP-initiated flow correctly authenticates users
  • SAML assertions use SHA-256 signatures
  • Attribute mapping correctly populates user profile
  • Session timeout forces re-authentication
  • SLO properly terminates sessions on both IdP and SP
  • Certificate rotation tested without service interruption

Other files in this skill

assets/template.md (verbatim)

SAML SSO Implementation Checklist Template

Project Information

Field Value
Service Provider [Application Name]
Identity Provider Okta
Implementation Lead [Name]
Target Go-Live Date [Date]
Environment [ ] Development [ ] Staging [ ] Production

Pre-Implementation Checklist

IdP (Okta) Configuration

  • Okta organization provisioned and accessible
  • Administrative access to Okta confirmed
  • Okta MFA enabled for admin accounts
  • Application created in Okta (SAML 2.0)
  • SSO URL configured: ____________________________
  • Audience URI (SP Entity ID) set: ____________________________
  • Name ID Format selected: [ ] Email [ ] Persistent [ ] Transient
  • Attribute statements configured:
    • email -> user.email
    • firstName -> user.firstName
    • lastName -> user.lastName
    • groups -> (group attribute filter)
  • Signature algorithm set to SHA-256
  • Response signed: [ ] Yes [ ] No
  • Assertion signed: [ ] Yes [ ] No
  • Assertion encryption enabled: [ ] Yes [ ] No
  • Users/Groups assigned to application

SP Configuration

  • SP SAML library installed and configured
  • ACS URL endpoint implemented: ____________________________
  • SP Entity ID configured: ____________________________
  • IdP metadata imported (certificate, SSO URL, Entity ID)
  • Signature validation implemented (SHA-256)
  • InResponseTo validation enabled
  • Audience restriction validation enabled
  • Time condition validation with clock skew tolerance
  • Session creation after successful assertion
  • Error handling for failed assertions

Security Configuration

  • All endpoints use HTTPS
  • SHA-256 enforced (SHA-1 rejected)
  • Assertion encryption with AES-256-CBC
  • Certificate pinning or strong validation
  • CSRF protection on ACS endpoint
  • Rate limiting on authentication endpoints
  • Session timeout configured: ____ minutes
  • Idle timeout configured: ____ minutes
  • Single Logout (SLO) endpoint configured

Certificate Management

Current Certificate

Field Value
Issuer
Subject
Serial Number
Valid From
Valid To
SHA-256 Fingerprint
Algorithm

Certificate Rotation Schedule

Date Action Status
Generate new certificate in Okta [ ] Done
Distribute new certificate to SP team [ ] Done
Install new certificate on SP (dual-cert) [ ] Done
Activate new certificate on Okta [ ] Done
Monitor for authentication failures [ ] Done
Remove old certificate from SP [ ] Done

Testing Checklist

SP-Initiated SSO

  • User redirected to Okta login page
  • Successful authentication creates SP session
  • User attributes correctly mapped
  • Group memberships correctly populated
  • Invalid credentials properly rejected
  • MFA prompt appears when configured

IdP-Initiated SSO

  • Login from Okta dashboard tile works
  • Session created correctly on SP
  • Deep links preserved after authentication

Single Logout

  • SP-initiated logout terminates IdP session
  • IdP-initiated logout terminates SP session
  • All session cookies properly cleared

Error Scenarios

  • Expired assertion rejected
  • Invalid signature rejected
  • Wrong audience URI rejected
  • Replay attack prevented (InResponseTo)
  • Clock skew beyond tolerance rejected

Post-Implementation

Monitoring

  • Authentication success/failure alerts configured
  • Certificate expiration monitoring (30-day warning)
  • Okta System Log integration with SIEM
  • SP authentication logs forwarded to SIEM
  • Dashboard for SSO health metrics

Documentation

  • Architecture diagram updated
  • Runbook for SSO troubleshooting created
  • Certificate rotation procedure documented
  • Break-glass access procedure documented
  • User communication sent

Sign-Off

Role Name Date Signature
Security Lead
Application Owner
IAM Team Lead
Change Manager

references/api-reference.md (verbatim)

API Reference: Implementing SAML SSO with Okta

Okta Admin API Endpoints

Endpoint Method Purpose
/api/v1/apps GET List applications (filter by SAML)
/api/v1/apps/{id}/sso/saml/metadata GET Retrieve SAML metadata XML
/api/v1/apps/{id}/users GET List user assignments
/api/v1/apps/{id}/groups GET List group assignments
/api/v1/policies?type=OKTA_SIGN_ON GET Check MFA policies

SAML Security Checks

Check Severity Description
SHA-256 signature High SignatureMethod must not use SHA-1
Assertion encryption Medium Encrypt assertions in transit
AudienceRestriction High Must limit assertion audience
Certificate expiry Critical Monitor signing cert expiration
SingleLogoutService Medium SLO endpoint should be configured
MFA enforcement High Require MFA for SAML authentication

SAML XML Namespaces

Prefix URI
md urn:oasis:names:tc:SAML:2.0:metadata
ds http://www.w3.org/2000/09/xmldsig#
saml urn:oasis:names:tc:SAML:2.0:assertion

Python Libraries

Library Version Purpose
requests >=2.28 Okta API communication
xml.etree.ElementTree stdlib SAML metadata parsing
ssl stdlib Certificate expiry checking

References

references/standards.md (verbatim)

Standards and References - SAML SSO with Okta

SAML 2.0 Standards

NIST Standards

Okta Documentation

Security Best Practices

XML Security Standards

  • XML Signature (XMLDSig): W3C standard for XML digital signatures
  • XML Encryption: W3C standard for encrypting XML content
  • XML Canonicalization (C14N): Required for consistent signature verification

Compliance Frameworks

  • SOC 2 Type II: Logical access controls through SSO
  • ISO 27001: A.9.4.2 Secure log-on procedures
  • PCI DSS 4.0: Requirement 8 - Identify Users and Authenticate Access

references/workflows.md (verbatim)

SAML SSO Implementation Workflows

Workflow 1: SP-Initiated SSO Flow

User -> Service Provider -> Okta IdP -> User Authenticates -> Okta -> Service Provider -> User

Detailed Steps:

  1. User accesses protected resource on Service Provider
  2. SP checks for existing session - none found
  3. SP generates SAML AuthnRequest with:
    • Issuer (SP Entity ID)
    • AssertionConsumerServiceURL
    • NameIDPolicy (email format)
    • RequestID (for InResponseTo validation)
  4. SP redirects user to Okta SSO URL with base64-encoded AuthnRequest
  5. Okta authenticates user (credentials, MFA if configured)
  6. Okta generates SAML Response containing:
    • Signed assertion with SHA-256
    • Subject NameID (user identifier)
    • Conditions (NotBefore, NotOnOrAfter, AudienceRestriction)
    • AuthnStatement (authentication context)
    • AttributeStatement (mapped user attributes)
  7. Okta POSTs SAML Response to SP ACS URL
  8. SP validates SAML Response:
    • Verify XML signature against Okta certificate
    • Check InResponseTo matches original request ID
    • Validate time conditions (with clock skew tolerance)
    • Verify audience restriction matches SP Entity ID
    • Check authentication context class
  9. SP extracts user identity and attributes
  10. SP creates local session and grants access

Workflow 2: IdP-Initiated SSO Flow

Steps:

  1. User logs into Okta dashboard
  2. User clicks on application tile
  3. Okta generates unsolicited SAML Response (no InResponseTo)
  4. Okta POSTs to SP ACS URL
  5. SP validates assertion (no InResponseTo check)
  6. SP creates session

Security Note:

IdP-initiated SSO is less secure because it cannot validate InResponseTo, making it more susceptible to replay attacks. Use SP-initiated flow when possible.

Workflow 3: Certificate Rotation

Steps:

  1. Generate new X.509 certificate in Okta (Admin > Settings > Security)
  2. Download new certificate (do not yet set as active)
  3. Install new certificate on SP alongside existing certificate
  4. Configure SP to accept assertions signed with either certificate
  5. Activate new certificate in Okta
  6. Monitor for authentication failures
  7. After validation period, remove old certificate from SP
  8. Update SAML metadata on both sides

Timeline:

  • Day 0: Generate new certificate and distribute to SP team
  • Day 1-7: SP installs new certificate (dual-cert mode)
  • Day 8: Activate new certificate in Okta
  • Day 8-14: Monitor authentication logs for failures
  • Day 15: Remove old certificate from SP

Workflow 4: Single Logout (SLO)

Steps:

  1. User initiates logout at SP
  2. SP generates SAML LogoutRequest
  3. SP sends LogoutRequest to Okta SLO endpoint
  4. Okta terminates IdP session
  5. Okta sends LogoutRequest to all other SPs in session
  6. Each SP terminates local session
  7. Okta sends LogoutResponse to initiating SP
  8. SP confirms logout to user

Workflow 5: Troubleshooting Authentication Failures

Diagnostic Steps:

  1. Install SAML Tracer browser extension
  2. Reproduce the failed SSO attempt
  3. Capture the SAML AuthnRequest and Response
  4. Check for common issues:
    • Signature Invalid: Certificate mismatch or SHA-1 vs SHA-256
    • Audience Mismatch: SP Entity ID doesn't match Okta config
    • Time Condition Failed: Clock skew > configured tolerance
    • NameID Format Mismatch: SP expects different format
    • Missing Attributes: Attribute mapping not configured
  5. Review Okta System Log for error details
  6. Verify SP metadata matches Okta configuration

Back to mukul975/Anthropic-Cybersecurity-Skills (817 security skills) or Agent skills.