managing-cloud-identity-with-okta

What this skill does

# Managing Cloud Identity with Okta

## When to Use

- When centralizing authentication across AWS, Azure, and GCP console access through a single identity provider
- When implementing phishing-resistant MFA to replace SMS or TOTP-based authentication
- When automating user provisioning and deprovisioning across cloud platforms and SaaS applications
- When enforcing adaptive access policies based on device compliance, user risk, and network context
- When auditing identity-related security controls for SOC 2 or zero trust compliance

**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).

## Prerequisites

- Okta organization with admin console access and appropriate license tier (Workforce Identity)
- AWS, Azure, and GCP accounts configured for SAML or OIDC federation
- Okta Universal Directory populated with user identities synced from HR system or Active Directory
- Device management platform (Intune, Jamf) for device trust integration

## Workflow

### Step 1: Configure SSO Integration with Cloud Providers

Set up SAML 2.0 or OIDC federation between Okta and each cloud provider console for centralized authentication.

```
Okta AWS SSO Integration (SAML 2.0):
1. In Okta Admin Console: Applications > Add Application > AWS Account Federation
2. Configure SAML settings:
   - Single Sign-On URL: https://signin.aws.amazon.com/saml
   - Audience URI: urn:amazon:webservices
   - Attribute Statements:
     - https://aws.amazon.com/SAML/Attributes/RoleSessionName -> user.email
     - https://aws.amazon.com/SAML/Attributes/Role -> appuser.awsRoles
3. Download Okta metadata XML
4. In AWS IAM: Create Identity Provider (SAML) with Okta metadata
5. Create IAM roles with trust policy referencing the Okta SAML provider

AWS IAM Trust Policy:
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789012:saml-provider/Okta"
    },
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "SAML:aud": "https://signin.aws.amazon.com/saml"
      }
    }
  }]
}
```

```bash
# Azure AD integration via OIDC
# Configure Okta as external IdP in Azure AD
az ad sp create --id <okta-app-client-id>

# GCP integration via Workforce Identity Federation
gcloud iam workforce-pools create okta-pool \
  --organization=123456789 \
  --location=global \
  --display-name="Okta Workforce Pool"

gcloud iam workforce-pools providers create-oidc okta-provider \
  --workforce-pool=okta-pool \
  --location=global \
  --issuer-uri="https://company.okta.com/oauth2/default" \
  --client-id="gcp-workforce-client-id" \
  --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups"
```

### Step 2: Deploy Phishing-Resistant MFA

Enable Okta FastPass and FIDO2 WebAuthn authenticators as phishing-resistant MFA factors. Configure policies requiring these factors for privileged cloud access.

```
Okta MFA Policy Configuration:
1. Security > Authenticators:
   - Enable Okta Verify (FastPass) - Phishing resistant
   - Enable FIDO2 (WebAuthn) - Hardware security keys
   - Disable SMS and Voice (phishable)

2. Authentication Policies > Cloud Admin Access:
   - Rule: "Require phishing-resistant MFA for AWS/Azure/GCP admin roles"
   - Factor Types: Okta FastPass OR FIDO2 WebAuthn
   - Re-authentication: Every 4 hours for admin consoles
   - Session Lifetime: 8 hours maximum

3. Device Trust Policy:
   - Require managed device for cloud admin access
   - Require device encryption enabled
   - Require OS version within 90 days of latest
```

### Step 3: Automate User Lifecycle Management

Configure SCIM provisioning to automatically create and deactivate user accounts in cloud services when employees join, change roles, or leave the organization.

```
Okta Lifecycle Management:
1. Provisioning Configuration (AWS IAM Identity Center):
   - Enable SCIM provisioning to AWS IAM Identity Center
   - Map Okta groups to AWS permission sets
   - Configure attribute mapping: email, displayName, groups

2. Automation Rules:
   - On User Activation: Provision to AWS, Azure, GCP based on department group
   - On Group Change: Update cloud role assignments within 15 minutes
   - On User Deactivation: Immediately revoke all cloud sessions and permissions
   - On Suspension: Disable cloud accounts, preserve data for 30 days

3. Offboarding Workflow:
   - HR triggers deactivation in Workday/BambooHR
   - Okta receives SCIM event, deactivates user in Universal Directory
   - All SSO sessions terminated across AWS, Azure, GCP
   - SCIM deprovisioning removes user from cloud platforms
   - Audit log entry created for compliance evidence
```

### Step 4: Configure Adaptive Access Policies

Create context-aware authentication policies that evaluate risk signals including device posture, network location, user behavior, and threat intelligence.

```
Adaptive Access Policy Examples:

Policy 1: "High-Risk Cloud Admin Access"
  IF: User is in "Cloud Admins" group
  AND: Accessing AWS Console, Azure Portal, or GCP Console
  THEN:
    - Require phishing-resistant MFA (FastPass or FIDO2)
    - Require managed and compliant device
    - Block access from anonymous proxies or Tor
    - Session duration: 4 hours
    - Re-authentication: Every 2 hours for sensitive actions

Policy 2: "Standard Cloud Developer Access"
  IF: User is in "Developers" group
  AND: Accessing non-admin cloud resources
  THEN:
    - Require any MFA factor (FastPass, TOTP, or push notification)
    - Allow unmanaged devices with step-up verification
    - Session duration: 8 hours
    - Block access from countries outside operating regions

Policy 3: "Emergency Break-Glass Access"
  IF: User is in "Emergency Admins" group
  AND: Break-glass request approved in ServiceNow
  THEN:
    - Require FIDO2 hardware key only
    - Log all actions to immutable audit trail
    - Session duration: 1 hour maximum
    - Notify SOC team via automated alert
```

### Step 5: Monitor Identity Threats with Okta ThreatInsight

Enable Okta ThreatInsight and system log monitoring to detect credential stuffing, account takeover, and suspicious authentication patterns.

```bash
# Query Okta System Log for security events via API
curl -s -H "Authorization: SSWS ${OKTA_API_TOKEN}" \
  "https://company.okta.com/api/v1/logs?filter=eventType+eq+%22user.session.start%22+and+outcome.result+eq+%22FAILURE%22&since=$(date -d '-24 hours' +%Y-%m-%dT%H:%M:%SZ)" | \
  jq '.[] | {time: .published, actor: .actor.displayName, ip: .client.ipAddress, result: .outcome.reason}'

# Export Okta logs to SIEM via Log Streaming
# Configure in Okta Admin > Reports > Log Streaming
# Supported targets: Splunk Cloud, AWS EventBridge, Datadog
```

## Key Concepts

| Term | Definition |
|------|------------|
| Okta FastPass | Phishing-resistant passwordless MFA that cryptographically binds authentication to the device and origin, preventing real-time phishing attacks |
| SCIM Provisioning | System for Cross-domain Identity Management protocol that automates user creation, update, and deletion across cloud applications |
| Universal Directory | Okta's cloud-based identity store that aggregates user profiles from multiple sources including AD, LDAP, and HR systems |
| Adaptive MFA | Context-aware authentication that adjusts MFA requirements based on risk signals such as device trust, location, and behavior |
| Workforce Identity | Okta product tier focused on employee and contractor identity management including SSO, MFA, and lifecycle management |
| ThreatInsight | Okta's threat detection service that identifies and blocks credential stuffing, password spraying, and bot-driven authentication attacks |
| Device Trust | Integration with MDM platforms to verify device compliance (encryption, OS versi