[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFGYSZPP5Q8HB5Q35CVCPF":3,"skill-same:01M6AFGYSZPP5Q8HB5Q35CVCPF":136},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":95,"commitSha":96,"skillDirectory":97,"forksCount":98,"repositoryHtmlUrl":99,"repositoryHomepageUrl":100,"ownerHtmlUrl":101,"ownerBlogUrl":102,"ownerDescription":103,"updatedAt":104,"install":105,"resources":118},"01M6AFGYSZPP5Q8HB5Q35CVCPF","managing-cloud-identity-with-okta",null,"Implement Okta as a centralized cloud identity provider: configure SSO with AWS, Azure, and GCP, deploy phishing-resistant MFA with Okta FastPass, automate user provisioning\u002Fdeprovisioning, and enforce adaptive access policies on device posture and risk signals. Use when standing up Okta SSO, rolling out FastPass MFA, automating identity lifecycle, or building risk-based conditional access for cloud environments.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35990,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-cloud-identity-with-okta\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"managing cloud identity with okta","identity","okta","cloud","gcp","phishing-resistant-MFA","lifecycle","t1566","initial-access","risk","t1078","sso","security","phishing","cloud-security","authentication","pr","azure","implement","cybersecurity","2026-11-10 10:12:30",false,"---\nname: managing-cloud-identity-with-okta\ndescription: >-\n  Implement Okta as a centralized cloud identity provider: configure SSO with AWS,\n  Azure, and GCP, deploy phishing-resistant MFA with Okta FastPass, automate user\n  provisioning\u002Fdeprovisioning, and enforce adaptive access policies on device posture\n  and risk signals. Use when standing up Okta SSO, rolling out FastPass MFA, automating\n  identity lifecycle, or building risk-based conditional access for cloud environments.\ndomain: cybersecurity\nsubdomain: cloud-security\ntags:\n- okta\n- cloud-identity\n- single-sign-on\n- phishing-resistant-mfa\n- identity-lifecycle\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.IR-01\n- ID.AM-08\n- GV.SC-06\n- DE.CM-01\nmitre_attack:\n- T1078.004\n- T1530\n- T1537\n- T1580\n- T1566\nmitre_f3:\n  version: '1.1'\n  tactics:\n  - initial-access\n  - positioning\n  techniques:\n  - id: F1006\n    name: Account Takeover\n    tactic: initial-access\n    source: f3\n  - id: F1006.002\n    name: 'Account Takeover: Exposed Login Credential'\n    tactic: initial-access\n    source: f3\n  - id: T1110.004\n    name: 'Brute Force:  Credential Stuffing'\n    tactic: initial-access\n    source: attack\n  - id: T1110.003\n    name: 'Brute Force: Password Spraying'\n    tactic: initial-access\n    source: attack\n  - id: T1539\n    name: Steal Web Session Cookie\n    tactic: positioning\n    source: attack\n  - id: T1550.001\n    name: 'Use Alternate Authentication Material: Application Access Token'\n    tactic: initial-access\n    source: attack\n---\n\n# Managing Cloud Identity with Okta\n\n## When to Use\n\n- When centralizing authentication across AWS, Azure, and GCP console access through a single identity provider\n- When implementing phishing-resistant MFA to replace SMS or TOTP-based authentication\n- When automating user provisioning and deprovisioning across cloud platforms and SaaS applications\n- When enforcing adaptive access policies based on device compliance, user risk, and network context\n- When auditing identity-related security controls for SOC 2 or zero trust compliance\n\n**Do not use** for cloud-native identity management without external IdP requirements (use AWS IAM Identity Center or Azure AD natively), for application-level authorization logic, or for secrets management (see implementing-secrets-management-with-vault).\n\n## Prerequisites\n\n- Okta organization with admin console access and appropriate license tier (Workforce Identity)\n- AWS, Azure, and GCP accounts configured for SAML or OIDC federation\n- Okta Universal Directory populated with user identities synced from HR system or Active Directory\n- Device management platform (Intune, Jamf) for device trust integration\n\n## Workflow\n\n### Step 1: Configure SSO Integration with Cloud Providers\n\nSet up SAML 2.0 or OIDC federation between Okta and each cloud provider console for centralized authentication.\n\n```\nOkta AWS SSO Integration (SAML 2.0):\n1. In Okta Admin Console: Applications > Add Application > AWS Account Federation\n2. Configure SAML settings:\n   - Single Sign-On URL: https:\u002F\u002Fsignin.aws.amazon.com\u002Fsaml\n   - Audience URI: urn:amazon:webservices\n   - Attribute Statements:\n     - https:\u002F\u002Faws.amazon.com\u002FSAML\u002FAttributes\u002FRoleSessionName -> user.email\n     - https:\u002F\u002Faws.amazon.com\u002FSAML\u002FAttributes\u002FRole -> appuser.awsRoles\n3. Download Okta metadata XML\n4. In AWS IAM: Create Identity Provider (SAML) with Okta metadata\n5. Create IAM roles with trust policy referencing the Okta SAML provider\n\nAWS IAM Trust Policy:\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [{\n    \"Effect\": \"Allow\",\n    \"Principal\": {\n      \"Federated\": \"arn:aws:iam::123456789012:saml-provider\u002FOkta\"\n    },\n    \"Action\": \"sts:AssumeRoleWithSAML\",\n    \"Condition\": {\n      \"StringEquals\": {\n        \"SAML:aud\": \"https:\u002F\u002Fsignin.aws.amazon.com\u002Fsaml\"\n      }\n    }\n  }]\n}\n```\n\n```bash\n# Azure AD integration via OIDC\n# Configure Okta as external IdP in Azure AD\naz ad sp create --id \u003Cokta-app-client-id>\n\n# GCP integration via Workforce Identity Federation\ngcloud iam workforce-pools create okta-pool \\\n  --organization=123456789 \\\n  --location=global \\\n  --display-name=\"Okta Workforce Pool\"\n\ngcloud iam workforce-pools providers create-oidc okta-provider \\\n  --workforce-pool=okta-pool \\\n  --location=global \\\n  --issuer-uri=\"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\" \\\n  --client-id=\"gcp-workforce-client-id\" \\\n  --attribute-mapping=\"google.subject=assertion.sub,google.groups=assertion.groups\"\n```\n\n### Step 2: Deploy Phishing-Resistant MFA\n\nEnable Okta FastPass and FIDO2 WebAuthn authenticators as phishing-resistant MFA factors. Configure policies requiring these factors for privileged cloud access.\n\n```\nOkta MFA Policy Configuration:\n1. Security > Authenticators:\n   - Enable Okta Verify (FastPass) - Phishing resistant\n   - Enable FIDO2 (WebAuthn) - Hardware security keys\n   - Disable SMS and Voice (phishable)\n\n2. Authentication Policies > Cloud Admin Access:\n   - Rule: \"Require phishing-resistant MFA for AWS\u002FAzure\u002FGCP admin roles\"\n   - Factor Types: Okta FastPass OR FIDO2 WebAuthn\n   - Re-authentication: Every 4 hours for admin consoles\n   - Session Lifetime: 8 hours maximum\n\n3. Device Trust Policy:\n   - Require managed device for cloud admin access\n   - Require device encryption enabled\n   - Require OS version within 90 days of latest\n```\n\n### Step 3: Automate User Lifecycle Management\n\nConfigure SCIM provisioning to automatically create and deactivate user accounts in cloud services when employees join, change roles, or leave the organization.\n\n```\nOkta Lifecycle Management:\n1. Provisioning Configuration (AWS IAM Identity Center):\n   - Enable SCIM provisioning to AWS IAM Identity Center\n   - Map Okta groups to AWS permission sets\n   - Configure attribute mapping: email, displayName, groups\n\n2. Automation Rules:\n   - On User Activation: Provision to AWS, Azure, GCP based on department group\n   - On Group Change: Update cloud role assignments within 15 minutes\n   - On User Deactivation: Immediately revoke all cloud sessions and permissions\n   - On Suspension: Disable cloud accounts, preserve data for 30 days\n\n3. Offboarding Workflow:\n   - HR triggers deactivation in Workday\u002FBambooHR\n   - Okta receives SCIM event, deactivates user in Universal Directory\n   - All SSO sessions terminated across AWS, Azure, GCP\n   - SCIM deprovisioning removes user from cloud platforms\n   - Audit log entry created for compliance evidence\n```\n\n### Step 4: Configure Adaptive Access Policies\n\nCreate context-aware authentication policies that evaluate risk signals including device posture, network location, user behavior, and threat intelligence.\n\n```\nAdaptive Access Policy Examples:\n\nPolicy 1: \"High-Risk Cloud Admin Access\"\n  IF: User is in \"Cloud Admins\" group\n  AND: Accessing AWS Console, Azure Portal, or GCP Console\n  THEN:\n    - Require phishing-resistant MFA (FastPass or FIDO2)\n    - Require managed and compliant device\n    - Block access from anonymous proxies or Tor\n    - Session duration: 4 hours\n    - Re-authentication: Every 2 hours for sensitive actions\n\nPolicy 2: \"Standard Cloud Developer Access\"\n  IF: User is in \"Developers\" group\n  AND: Accessing non-admin cloud resources\n  THEN:\n    - Require any MFA factor (FastPass, TOTP, or push notification)\n    - Allow unmanaged devices with step-up verification\n    - Session duration: 8 hours\n    - Block access from countries outside operating regions\n\nPolicy 3: \"Emergency Break-Glass Access\"\n  IF: User is in \"Emergency Admins\" group\n  AND: Break-glass request approved in ServiceNow\n  THEN:\n    - Require FIDO2 hardware key only\n    - Log all actions to immutable audit trail\n    - Session duration: 1 hour maximum\n    - Notify SOC team via automated alert\n```\n\n### Step 5: Monitor Identity Threats with Okta ThreatInsight\n\nEnable Okta ThreatInsight and system log monitoring to detect credential stuffing, account takeover, and suspicious authentication patterns.\n\n```bash\n# Query Okta System Log for security events via API\ncurl -s -H \"Authorization: SSWS ${OKTA_API_TOKEN}\" \\\n  \"https:\u002F\u002Fcompany.okta.com\u002Fapi\u002Fv1\u002Flogs?filter=eventType+eq+%22user.session.start%22+and+outcome.result+eq+%22FAILURE%22&since=$(date -d '-24 hours' +%Y-%m-%dT%H:%M:%SZ)\" | \\\n  jq '.[] | {time: .published, actor: .actor.displayName, ip: .client.ipAddress, result: .outcome.reason}'\n\n# Export Okta logs to SIEM via Log Streaming\n# Configure in Okta Admin > Reports > Log Streaming\n# Supported targets: Splunk Cloud, AWS EventBridge, Datadog\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Okta FastPass | Phishing-resistant passwordless MFA that cryptographically binds authentication to the device and origin, preventing real-time phishing attacks |\n| SCIM Provisioning | System for Cross-domain Identity Management protocol that automates user creation, update, and deletion across cloud applications |\n| Universal Directory | Okta's cloud-based identity store that aggregates user profiles from multiple sources including AD, LDAP, and HR systems |\n| Adaptive MFA | Context-aware authentication that adjusts MFA requirements based on risk signals such as device trust, location, and behavior |\n| Workforce Identity | Okta product tier focused on employee and contractor identity management including SSO, MFA, and lifecycle management |\n| ThreatInsight | Okta's threat detection service that identifies and blocks credential stuffing, password spraying, and bot-driven authentication attacks |\n| Device Trust | Integration with MDM platforms to verify device compliance (encryption, OS version, management status) before granting access |\n\n## Tools & Systems\n\n- **Okta Identity Engine**: Core identity platform providing SSO, MFA, lifecycle management, and adaptive access policies\n- **Okta Workflows**: No-code automation platform for building identity-driven workflows across cloud services\n- **Okta Advanced Server Access**: SSH and RDP access management for cloud servers using short-lived certificates\n- **AWS IAM Identity Center**: AWS-native SSO service that integrates with Okta as an external identity provider\n- **Azure AD External Identities**: Azure service for federating with Okta for B2B and workforce scenarios\n\n## Common Scenarios\n\n### Scenario: Automating Offboarding Across Multi-Cloud Environment\n\n**Context**: An employee with AWS admin, Azure contributor, and GCP editor access leaves the company. The organization needs to revoke all access within 15 minutes of HR processing the termination.\n\n**Approach**:\n1. HR deactivates the employee in Workday, triggering a SCIM event to Okta\n2. Okta immediately deactivates the user in Universal Directory, terminating all active SSO sessions\n3. SCIM deprovisioning removes the user from AWS IAM Identity Center, Azure AD, and GCP Workforce Identity\n4. Okta Workflow triggers additional cleanup: revoke OAuth tokens, remove from Slack, disable VPN certificate\n5. An audit log entry is created with timestamps for each deprovisioning action as compliance evidence\n6. SOC receives notification to verify no residual access exists through direct IAM users or service accounts\n\n**Pitfalls**: Not deprovisioning direct IAM users or service accounts created outside of Okta federation leaves backdoor access. SCIM propagation delays in some services can leave access active for minutes after Okta deactivation.\n\n## Output Format\n\n```\nCloud Identity Security Report\n================================\nIdentity Provider: Okta (company.okta.com)\nReport Date: 2025-02-23\n\nUSER STATISTICS:\n  Total Users: 2,450\n  Active: 2,312 | Suspended: 45 | Deactivated: 93\n  MFA Enrolled: 2,298\u002F2,312 (99.4%)\n  Phishing-Resistant MFA: 812\u002F2,312 (35.1%)\n\nCLOUD SSO COVERAGE:\n  AWS Console (45 accounts):     100% via SAML federation\n  Azure Portal (8 subscriptions): 100% via OIDC federation\n  GCP Console (3 projects):       100% via Workforce Identity\n\nAUTHENTICATION EVENTS (Last 30 Days):\n  Total Logins: 145,234\n  MFA Challenges: 89,456\n  Failed Logins: 3,456\n  Account Lockouts: 23\n  ThreatInsight Blocks: 12,345 (credential stuffing attempts)\n\nLIFECYCLE EVENTS:\n  Users Provisioned: 45\n  Users Deprovisioned: 23\n  Average Deprovisioning Time: 8 minutes\n  Orphan Accounts Detected: 3 (direct IAM users not managed by Okta)\n\nRECOMMENDATIONS:\n  [HIGH] Increase phishing-resistant MFA adoption from 35% to 80%\n  [HIGH] Remediate 3 orphan cloud accounts not managed by Okta\n  [MEDIUM] Reduce session duration for admin roles from 8h to 4h\n```\n","# Managing Cloud Identity with Okta\n\n## When to Use\n\n- When centralizing authentication across AWS, Azure, and GCP console access through a single identity provider\n- When implementing phishing-resistant MFA to replace SMS or TOTP-based authentication\n- When automating user provisioning and deprovisioning across cloud platforms and SaaS applications\n- When enforcing adaptive access policies based on device compliance, user risk, and network context\n- When auditing identity-related security controls for SOC 2 or zero trust compliance\n\n**Do not use** for cloud-native identity management without external IdP requirements (use AWS IAM Identity Center or Azure AD natively), for application-level authorization logic, or for secrets management (see implementing-secrets-management-with-vault).\n\n## Prerequisites\n\n- Okta organization with admin console access and appropriate license tier (Workforce Identity)\n- AWS, Azure, and GCP accounts configured for SAML or OIDC federation\n- Okta Universal Directory populated with user identities synced from HR system or Active Directory\n- Device management platform (Intune, Jamf) for device trust integration\n\n## Workflow\n\n### Step 1: Configure SSO Integration with Cloud Providers\n\nSet up SAML 2.0 or OIDC federation between Okta and each cloud provider console for centralized authentication.\n\n```\nOkta AWS SSO Integration (SAML 2.0):\n1. In Okta Admin Console: Applications > Add Application > AWS Account Federation\n2. Configure SAML settings:\n   - Single Sign-On URL: https:\u002F\u002Fsignin.aws.amazon.com\u002Fsaml\n   - Audience URI: urn:amazon:webservices\n   - Attribute Statements:\n     - https:\u002F\u002Faws.amazon.com\u002FSAML\u002FAttributes\u002FRoleSessionName -> user.email\n     - https:\u002F\u002Faws.amazon.com\u002FSAML\u002FAttributes\u002FRole -> appuser.awsRoles\n3. Download Okta metadata XML\n4. In AWS IAM: Create Identity Provider (SAML) with Okta metadata\n5. Create IAM roles with trust policy referencing the Okta SAML provider\n\nAWS IAM Trust Policy:\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [{\n    \"Effect\": \"Allow\",\n    \"Principal\": {\n      \"Federated\": \"arn:aws:iam::123456789012:saml-provider\u002FOkta\"\n    },\n    \"Action\": \"sts:AssumeRoleWithSAML\",\n    \"Condition\": {\n      \"StringEquals\": {\n        \"SAML:aud\": \"https:\u002F\u002Fsignin.aws.amazon.com\u002Fsaml\"\n      }\n    }\n  }]\n}\n```\n\n```bash\n# Azure AD integration via OIDC\n# Configure Okta as external IdP in Azure AD\naz ad sp create --id \u003Cokta-app-client-id>\n\n# GCP integration via Workforce Identity Federation\ngcloud iam workforce-pools create okta-pool \\\n  --organization=123456789 \\\n  --location=global \\\n  --display-name=\"Okta Workforce Pool\"\n\ngcloud iam workforce-pools providers create-oidc okta-provider \\\n  --workforce-pool=okta-pool \\\n  --location=global \\\n  --issuer-uri=\"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\" \\\n  --client-id=\"gcp-workforce-client-id\" \\\n  --attribute-mapping=\"google.subject=assertion.sub,google.groups=assertion.groups\"\n```\n\n### Step 2: Deploy Phishing-Resistant MFA\n\nEnable Okta FastPass and FIDO2 WebAuthn authenticators as phishing-resistant MFA factors. Configure policies requiring these factors for privileged cloud access.\n\n```\nOkta MFA Policy Configuration:\n1. Security > Authenticators:\n   - Enable Okta Verify (FastPass) - Phishing resistant\n   - Enable FIDO2 (WebAuthn) - Hardware security keys\n   - Disable SMS and Voice (phishable)\n\n2. Authentication Policies > Cloud Admin Access:\n   - Rule: \"Require phishing-resistant MFA for AWS\u002FAzure\u002FGCP admin roles\"\n   - Factor Types: Okta FastPass OR FIDO2 WebAuthn\n   - Re-authentication: Every 4 hours for admin consoles\n   - Session Lifetime: 8 hours maximum\n\n3. Device Trust Policy:\n   - Require managed device for cloud admin access\n   - Require device encryption enabled\n   - Require OS version within 90 days of latest\n```\n\n### Step 3: Automate User Lifecycle Management\n\nConfigure SCIM provisioning to automatically create and deactivate user accounts in cloud services when employees join, change roles, or leave the organization.\n\n```\nOkta Lifecycle Management:\n1. Provisioning Configuration (AWS IAM Identity Center):\n   - Enable SCIM provisioning to AWS IAM Identity Center\n   - Map Okta groups to AWS permission sets\n   - Configure attribute mapping: email, displayName, groups\n\n2. Automation Rules:\n   - On User Activation: Provision to AWS, Azure, GCP based on department group\n   - On Group Change: Update cloud role assignments within 15 minutes\n   - On User Deactivation: Immediately revoke all cloud sessions and permissions\n   - On Suspension: Disable cloud accounts, preserve data for 30 days\n\n3. Offboarding Workflow:\n   - HR triggers deactivation in Workday\u002FBambooHR\n   - Okta receives SCIM event, deactivates user in Universal Directory\n   - All SSO sessions terminated across AWS, Azure, GCP\n   - SCIM deprovisioning removes user from cloud platforms\n   - Audit log entry created for compliance evidence\n```\n\n### Step 4: Configure Adaptive Access Policies\n\nCreate context-aware authentication policies that evaluate risk signals including device posture, network location, user behavior, and threat intelligence.\n\n```\nAdaptive Access Policy Examples:\n\nPolicy 1: \"High-Risk Cloud Admin Access\"\n  IF: User is in \"Cloud Admins\" group\n  AND: Accessing AWS Console, Azure Portal, or GCP Console\n  THEN:\n    - Require phishing-resistant MFA (FastPass or FIDO2)\n    - Require managed and compliant device\n    - Block access from anonymous proxies or Tor\n    - Session duration: 4 hours\n    - Re-authentication: Every 2 hours for sensitive actions\n\nPolicy 2: \"Standard Cloud Developer Access\"\n  IF: User is in \"Developers\" group\n  AND: Accessing non-admin cloud resources\n  THEN:\n    - Require any MFA factor (FastPass, TOTP, or push notification)\n    - Allow unmanaged devices with step-up verification\n    - Session duration: 8 hours\n    - Block access from countries outside operating regions\n\nPolicy 3: \"Emergency Break-Glass Access\"\n  IF: User is in \"Emergency Admins\" group\n  AND: Break-glass request approved in ServiceNow\n  THEN:\n    - Require FIDO2 hardware key only\n    - Log all actions to immutable audit trail\n    - Session duration: 1 hour maximum\n    - Notify SOC team via automated alert\n```\n\n### Step 5: Monitor Identity Threats with Okta ThreatInsight\n\nEnable Okta ThreatInsight and system log monitoring to detect credential stuffing, account takeover, and suspicious authentication patterns.\n\n```bash\n# Query Okta System Log for security events via API\ncurl -s -H \"Authorization: SSWS ${OKTA_API_TOKEN}\" \\\n  \"https:\u002F\u002Fcompany.okta.com\u002Fapi\u002Fv1\u002Flogs?filter=eventType+eq+%22user.session.start%22+and+outcome.result+eq+%22FAILURE%22&since=$(date -d '-24 hours' +%Y-%m-%dT%H:%M:%SZ)\" | \\\n  jq '.[] | {time: .published, actor: .actor.displayName, ip: .client.ipAddress, result: .outcome.reason}'\n\n# Export Okta logs to SIEM via Log Streaming\n# Configure in Okta Admin > Reports > Log Streaming\n# Supported targets: Splunk Cloud, AWS EventBridge, Datadog\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Okta FastPass | Phishing-resistant passwordless MFA that cryptographically binds authentication to the device and origin, preventing real-time phishing attacks |\n| SCIM Provisioning | System for Cross-domain Identity Management protocol that automates user creation, update, and deletion across cloud applications |\n| Universal Directory | Okta's cloud-based identity store that aggregates user profiles from multiple sources including AD, LDAP, and HR systems |\n| Adaptive MFA | Context-aware authentication that adjusts MFA requirements based on risk signals such as device trust, location, and behavior |\n| Workforce Identity | Okta product tier focused on employee and contractor identity management including SSO, MFA, and lifecycle management |\n| ThreatInsight | Okta's threat detection service that identifies and blocks credential stuffing, password spraying, and bot-driven authentication attacks |\n| Device Trust | Integration with MDM platforms to verify device compliance (encryption, OS version, management status) before granting access |\n\n## Tools & Systems\n\n- **Okta Identity Engine**: Core identity platform providing SSO, MFA, lifecycle management, and adaptive access policies\n- **Okta Workflows**: No-code automation platform for building identity-driven workflows across cloud services\n- **Okta Advanced Server Access**: SSH and RDP access management for cloud servers using short-lived certificates\n- **AWS IAM Identity Center**: AWS-native SSO service that integrates with Okta as an external identity provider\n- **Azure AD External Identities**: Azure service for federating with Okta for B2B and workforce scenarios\n\n## Common Scenarios\n\n### Scenario: Automating Offboarding Across Multi-Cloud Environment\n\n**Context**: An employee with AWS admin, Azure contributor, and GCP editor access leaves the company. The organization needs to revoke all access within 15 minutes of HR processing the termination.\n\n**Approach**:\n1. HR deactivates the employee in Workday, triggering a SCIM event to Okta\n2. Okta immediately deactivates the user in Universal Directory, terminating all active SSO sessions\n3. SCIM deprovisioning removes the user from AWS IAM Identity Center, Azure AD, and GCP Workforce Identity\n4. Okta Workflow triggers additional cleanup: revoke OAuth tokens, remove from Slack, disable VPN certificate\n5. An audit log entry is created with timestamps for each deprovisioning action as compliance evidence\n6. SOC receives notification to verify no residual access exists through direct IAM users or service accounts\n\n**Pitfalls**: Not deprovisioning direct IAM users or service accounts created outside of Okta federation leaves backdoor access. SCIM propagation delays in some services can leave access active for minutes after Okta deactivation.\n\n## Output Format\n\n```\nCloud Identity Security Report\n================================\nIdentity Provider: Okta (company.okta.com)\nReport Date: 2025-02-23\n\nUSER STATISTICS:\n  Total Users: 2,450\n  Active: 2,312 | Suspended: 45 | Deactivated: 93\n  MFA Enrolled: 2,298\u002F2,312 (99.4%)\n  Phishing-Resistant MFA: 812\u002F2,312 (35.1%)\n\nCLOUD SSO COVERAGE:\n  AWS Console (45 accounts):     100% via SAML federation\n  Azure Portal (8 subscriptions): 100% via OIDC federation\n  GCP Console (3 projects):       100% via Workforce Identity\n\nAUTHENTICATION EVENTS (Last 30 Days):\n  Total Logins: 145,234\n  MFA Challenges: 89,456\n  Failed Logins: 3,456\n  Account Lockouts: 23\n  ThreatInsight Blocks: 12,345 (credential stuffing attempts)\n\nLIFECYCLE EVENTS:\n  Users Provisioned: 45\n  Users Deprovisioned: 23\n  Average Deprovisioning Time: 8 minutes\n  Orphan Accounts Detected: 3 (direct IAM users not managed by Okta)\n\nRECOMMENDATIONS:\n  [HIGH] Increase phishing-resistant MFA adoption from 35% to 80%\n  [HIGH] Remediate 3 orphan cloud accounts not managed by Okta\n  [MEDIUM] Reduce session duration for admin roles from 8h to 4h\n```\n",{"name":5,"tags":52,"author":57,"domain":46,"license":15,"version":58,"mitre_f3":59,"nist_csf":84,"subdomain":41,"description":7,"mitre_attack":89},[29,53,54,55,56],"cloud-identity","single-sign-on","phishing-resistant-mfa","identity-lifecycle","mahipal","1.0.0",{"tactics":60,"version":62,"techniques":63},[35,61],"positioning","1.1",[64,68,71,75,78,81],{"id":65,"name":66,"source":67,"tactic":35},"F1006","Account Takeover","f3",{"id":69,"name":70,"source":67,"tactic":35},"F1006.002","Account Takeover: Exposed Login Credential",{"id":72,"name":73,"source":74,"tactic":35},"T1110.004","Brute Force:  Credential Stuffing","attack",{"id":76,"name":77,"source":74,"tactic":35},"T1110.003","Brute Force: Password Spraying",{"id":79,"name":80,"source":74,"tactic":61},"T1539","Steal Web Session Cookie",{"id":82,"name":83,"source":74,"tactic":35},"T1550.001","Use Alternate Authentication Material: Application Access Token",[85,86,87,88],"PR.IR-01","ID.AM-08","GV.SC-06","DE.CM-01",[90,91,92,93,94],"T1078.004","T1530","T1537","T1580","T1566","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fmanaging-cloud-identity-with-okta",4395,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":106,"prompt":116,"zipAvailable":117},[107,110,113],{"tool":108,"command":109},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill managing-cloud-identity-with-okta",{"tool":111,"command":112},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill managing-cloud-identity-with-okta",{"tool":114,"command":115},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill managing-cloud-identity-with-okta","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-cloud-identity-with-okta\u002FSKILL.md",true,[119,124,130],{"path":120,"resourceType":120,"resourceTypeDesc":121,"sizeBytes":122,"sourceHtmlUrl":123},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-cloud-identity-with-okta\u002FLICENSE",{"path":125,"resourceType":126,"resourceTypeDesc":127,"sizeBytes":128,"sourceHtmlUrl":129},"references\u002Fapi-reference.md","REFERENCE","参考文档",2436,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-cloud-identity-with-okta\u002Freferences\u002Fapi-reference.md",{"path":131,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":134,"sourceHtmlUrl":135},"scripts\u002Fagent.py","SCRIPT","脚本",7151,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-cloud-identity-with-okta\u002Fscripts\u002Fagent.py",[137,161,185,212,238,264],{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":144,"publishedAt":47},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[143],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[145,146,147,148,39,46,149,28,43,150,151,152,153,154,155,156,157,158,159,160],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":168,"publishedAt":47},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[167],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[169,157,170,171,39,172,46,43,173,174,175,176,177,178,179,180,181,182,183,184],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":195,"publishedAt":47},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[191,194],{"categoryNo":192,"categoryName":193,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[179,196,197,198,199,46,200,201,173,202,203,204,205,206,207,37,208,209,210,211],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":219,"publishedAt":47},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[218],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[220,221,222,46,223,224,225,226,227,228,229,230,231,232,233,234,176,235,236,237],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":239,"name":240,"nameZh":6,"description":241,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":242,"categories":243,"keywords":245,"publishedAt":47},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[244],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[246,247,248,46,249,250,251,252,253,254,255,256,257,258,36,259,260,261,262,263],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":265,"name":266,"nameZh":6,"description":267,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":268,"categories":269,"keywords":271,"publishedAt":47},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[270],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[39,272,46,273,274,275,276,277,278,279,280,37,281,208,282,283,284,285,286,287],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]