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"
      }
    }
  }]
}

# 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

…