mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-08-19 16:00:21 +03:00
- Add validated mitre_attack frontmatter to all 754 skills (286 distinct techniques), verified against MITRE ATT&CK v19.1 via the official mitreattack-python library: 0 revoked, deprecated, or invalid IDs - Curate precise per-skill technique IDs for forensics, malware-analysis, threat-intel, and red-team skills (e.g. DCSync -> T1003.006, Kerberoasting -> T1558.003, Pass-the-Ticket -> T1550.003) - Reconcile v19.1 tactic restructuring: Defense Evasion split into Stealth (TA0005) and Defense Impairment (TA0112); revoked T1562.* family and T1070.001/.002 remapped to active equivalents (T1685.*) - Normalize word-split tags across 35 skills (remove filename-derived stopword tags, add semantic cybersecurity tags) - Add api-reference.md for 3 skills that were missing it - Update README ATT&CK section with accurate v19.1 tactic distribution
5.8 KiB
5.8 KiB
name, description, domain, subdomain, tags, version, author, license, nist_csf, mitre_attack
| name | description | domain | subdomain | tags | version | author | license | nist_csf | mitre_attack | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| implementing-saml-sso-with-okta | 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, a | cybersecurity | identity-access-management |
|
1.0 | mahipal | Apache-2.0 |
|
|
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
- 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
- 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
- Navigate to Applications > Create App Integration
- Select SAML 2.0 as the sign-on method
- Configure General Settings (App Name, Logo)
- Set Single Sign-On URL (ACS URL)
- Set Audience URI (SP Entity ID)
- Configure Name ID Format and Application Username
Step 2: Configure Attribute Mapping
- Map
user.emailtoemailattribute - Map
user.firstNameanduser.lastNameto 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