mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-07-19 14:09:40 +03:00
mukul975
886658219f
- Add mitre_f3 frontmatter block to 94 fraud-relevant skills (phishing, account takeover, banking malware, BEC, identity/KYC, payment/card fraud, money-mule/cash-out, ransomware extortion, DFIR, threat intel) - Map each skill to F3 v1.1 tactics + precise technique IDs, including the two F3-specific tactics ATT&CK lacks: Positioning (FA0001) and Monetization (FA0002) - All 123 F3 v1.1 technique IDs validated against the upstream STIX bundle (github.com/center-for-threat-informed-defense/fight-fraud-framework): 0 invalid IDs, 0 invalid tactics, 0 name mismatches, no placeholder IDs - mitre_f3 kept as a separate block from mitre_attack (F3 redefines several ATT&CK tactics for the fraud context) - Add docs/mitre-f3-mapping.md schema reference - Update README: F3 as the 6th framework, dedicated F3 section + badge
173 lines
6.5 KiB
Markdown
173 lines
6.5 KiB
Markdown
---
|
|
name: implementing-saml-sso-with-okta
|
|
description: 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
|
|
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
|