How do CDEs integrate with SSO?

Most CDEs support SAML 2.0 and OIDC for SSO integration with Okta, Azure AD, Google Workspace, and other identity providers. This enables single sign-on, centralized access control, and automatic session management.

What is SCIM provisioning for CDEs?

SCIM (System for Cross-domain Identity Management) automatically syncs users and groups from your identity provider to the CDE platform. When someone joins or leaves, their CDE access is automatically provisioned or revoked.

How should RBAC be configured for CDEs?

Define roles based on function: Developers (create/manage own workspaces), Team Leads (manage team templates), Platform Admins (full control), and Auditors (read-only access). Map to identity provider groups for automatic assignment.

IAM Implementation Guide for Cloud Development Environments

Comprehensive guide to Identity and Access Management for Coder, Gitpod, GitHub Codespaces, and other CDE platforms. Configure SSO, SCIM provisioning, RBAC, MFA, and enterprise-grade access controls.

Why IAM Matters for Cloud Development Environments

When developers access remote workspaces containing production credentials, proprietary code, and sensitive data, proper identity and access management is not optional - it's critical for security and compliance.

Authentication

Verify user identity through enterprise SSO providers (Okta, Azure AD, Google Workspace) with SAML 2.0 or OIDC protocols.

Single Sign-On (SSO)
Multi-Factor Authentication
Session Management

Authorization

Control what authenticated users can do with role-based access control (RBAC) and fine-grained permissions.

Role-Based Access Control
Permission Policies
Resource Isolation

Provisioning

Automate user lifecycle with SCIM (System for Cross-domain Identity Management) for instant onboarding and offboarding.

Automatic User Creation
Group Synchronization
Instant Deprovisioning

Single Sign-On Integration Guides

Step-by-step configuration for major identity providers

Okta SSO Integration

SAML 2.0 and OIDC Configuration

Option 1: SAML 2.0 Setup

Step 1: Create Okta Application

Log into Okta Admin Console
Navigate to Applications > Create App Integration
Select "SAML 2.0" as sign-in method
Name your application (e.g., "Coder CDE")

Step 2: Configure SAML Settings

Single Sign-On URL: https://your-coder-instance.com/api/v2/users/oidc/callback
Audience URI (SP Entity ID): https://your-coder-instance.com
Name ID Format: EmailAddress
Application Username: Email

Step 3: Attribute Mapping

email     -> user.email
firstName -> user.firstName
lastName  -> user.lastName
groups    -> user.groups (if using group-based roles)

Step 4: Configure CDE Platform

Add to your Coder Helm values or configuration:

coder:
  oidc:
    issuerURL: "https://your-org.okta.com"
    clientID: "your-okta-client-id"
    clientSecret: "your-okta-client-secret"
    emailDomain: "yourcompany.com"
    scopes: "openid,profile,email,groups"
    groupField: "groups"

Option 2: OpenID Connect (OIDC) Setup

Recommended for modern deployments. OIDC provides better token handling and refresh capabilities.

# In Okta, create an OIDC Web Application
Authorization Server: default
Grant Types: Authorization Code, Refresh Token
Redirect URIs: https://your-coder.com/api/v2/users/oidc/callback

# CDE Configuration (example for Coder)
CODER_OIDC_ISSUER_URL="https://your-org.okta.com/oauth2/default"
CODER_OIDC_CLIENT_ID="0oa..."
CODER_OIDC_CLIENT_SECRET="secret..."
CODER_OIDC_SCOPES="openid,profile,email,groups"

Azure AD / Entra ID Integration

Microsoft's Enterprise Identity Platform

Step 1: Register Application in Azure Portal

Navigate to Azure Active Directory > App Registrations
Click "New registration"
Name: "Coder CDE" (or your platform name)
Redirect URI (Web): https://your-coder.com/api/v2/users/oidc/callback

Step 2: Create Client Secret

In your app registration:

1. Go to "Certificates & secrets"
2. Click "New client secret"
3. Add description: "Coder OIDC Integration"
4. Set expiration (recommended: 12-24 months)
5. Copy the secret value immediately (won't be shown again)

Step 3: API Permissions

Grant the following Microsoft Graph permissions:

User.Read (Delegated)
email (Delegated)
profile (Delegated)
openid (Delegated)
Group.Read.All (Delegated) - for group-based RBAC

Step 4: Configure CDE Platform

CODER_OIDC_ISSUER_URL="https://login.microsoftonline.com/<tenant-id>/v2.0"
CODER_OIDC_CLIENT_ID="your-application-client-id"
CODER_OIDC_CLIENT_SECRET="your-client-secret-value"
CODER_OIDC_SCOPES="openid,profile,email,User.Read"
CODER_OIDC_EMAIL_DOMAIN="yourcompany.com"

# Optional: Group claims for RBAC
CODER_OIDC_GROUP_FIELD="groups"
CODER_OIDC_GROUP_AUTO_CREATE="true"

Azure AD Group Claims

To include groups in the ID token:

1. In App Registration, go to "Token configuration"
2. Add "groups" claim
3. Choose "Security groups" or "Directory roles"
4. Groups will appear in ID token as array of GUIDs

Google Workspace Integration

OAuth 2.0 with Google Cloud Platform

Step 1: Create OAuth 2.0 Client

Go to Google Cloud Console > APIs & Services > Credentials
Create OAuth 2.0 Client ID
Application type: Web application
Authorized redirect URIs: https://your-coder.com/api/v2/users/oidc/callback

Step 2: OAuth Consent Screen

User Type: Internal (for Workspace only)
Scopes:
  - openid
  - email
  - profile
  - https://www.googleapis.com/auth/userinfo.email
  - https://www.googleapis.com/auth/userinfo.profile

Step 3: CDE Configuration

CODER_OIDC_ISSUER_URL="https://accounts.google.com"
CODER_OIDC_CLIENT_ID="your-client-id.apps.googleusercontent.com"
CODER_OIDC_CLIENT_SECRET="your-client-secret"
CODER_OIDC_EMAIL_DOMAIN="yourcompany.com"
CODER_OIDC_SCOPES="openid,profile,email"

# Optional: Restrict to specific Google Workspace domain
CODER_OIDC_EMAIL_DOMAIN="yourcompany.com"

Important: Domain Restriction

Google OAuth doesn't provide group claims by default. For advanced group-based access control, consider using Google Cloud Identity API with service account credentials, or implement custom logic in your CDE platform to query Google Directory API after authentication.

SCIM Provisioning Setup

Automate user lifecycle management with System for Cross-domain Identity Management (SCIM 2.0). When an employee joins, leaves, or changes roles in your IdP, their CDE access updates automatically.

SCIM Benefits

Instant Onboarding: New hires get CDE access within seconds of being added to your IdP
Automatic Offboarding: Terminated employees lose access immediately when disabled in IdP
Group Sync: Role changes in IdP automatically update CDE permissions
Compliance: Single source of truth for user access (required for SOC 2, HITRUST)

SCIM vs Manual Provisioning

Without SCIM:

Manual user creation in each system
Risk of orphaned accounts
Delayed offboarding (security risk)
Manual role/group updates

With SCIM:

Automatic user provisioning
Instant deprovisioning
Real-time group synchronization
Audit trail of all changes

SCIM Configuration Examples

Okta SCIM Setup

# 1. In Coder (or your CDE), generate SCIM API token
coder scim generate-token --name "okta-scim"
# Output: scim_xxxxxxxxxxxxxxxxxxxxxxxx

# 2. In Okta Application Settings:
Provisioning > Integration > Edit
  SCIM Connector Base URL: https://your-coder.com/api/v2/scim/v2
  Unique Identifier Field: userName
  Supported Provisioning Actions:
    ☑ Push New Users
    ☑ Push Profile Updates
    ☑ Push Groups
  Authentication Mode: HTTP Header
    Authorization: Bearer scim_xxxxxxxxxxxxxxxxxxxxxxxx

# 3. Enable Provisioning Features:
To App:
  ☑ Create Users
  ☑ Update User Attributes
  ☑ Deactivate Users

Testing: Use Okta's "Test Provisioning" feature to verify connectivity before enabling for all users.

Azure AD / Entra ID SCIM Setup

# 1. Generate SCIM token in your CDE platform

# 2. In Azure Portal:
Enterprise Applications > Your App > Provisioning
  Provisioning Mode: Automatic

  Admin Credentials:
    Tenant URL: https://your-coder.com/api/v2/scim/v2
    Secret Token: scim_xxxxxxxxxxxxxxxxxxxxxxxx

  Click "Test Connection" to validate

# 3. Configure Mappings:
Attribute Mappings > Provision Azure Active Directory Users
  userPrincipalName -> userName
  displayName       -> displayName
  mail              -> emails[type eq "work"].value
  givenName         -> name.givenName
  surname           -> name.familyName
  accountEnabled    -> active

# 4. Set Provisioning Scope:
  - Sync only assigned users and groups (recommended)
  - Sync all users and groups (for full automation)

Note: Azure AD SCIM runs on a 40-minute sync cycle by default. For immediate provisioning, use the "Provision on demand" feature for individual users.

Google Workspace SCIM Limitations

Important: Google Workspace does not natively support SCIM provisioning for third-party applications. Workarounds include:

Google Cloud Identity: Use Directory API with service account to sync users programmatically
Third-party bridges: Tools like OneLogin or JumpCloud can act as SCIM intermediaries
Just-in-Time (JIT) provisioning: Users created on first SSO login (simpler but less control)

Role-Based Access Control (RBAC)

Define granular permissions based on job functions. Platform engineers manage infrastructure, developers create workspaces, and auditors have read-only access.

Standard Role Definitions

Admin

Full system access
User management
Template management
Audit log access
System configuration

Platform Engineer

Create/edit templates
Manage provisioners
View all workspaces
No user management
No system config

Developer

Create workspaces
Start/stop own workspaces
Use approved templates
No template editing
Own workspaces only

Viewer / Auditor

Read-only access
View templates
View workspace list
Access audit logs
No modifications

Permission Matrix

Permission	Admin	Platform Eng	Developer	Viewer
Create workspace
Delete own workspace
Delete any workspace
Create/edit templates
View all workspaces
Manage users
Manage groups/roles
View audit logs

Creating Custom Roles

Example: Create a "Template Developer" role that can edit templates but not manage users or system settings.

# Example for Coder (adjust syntax for your CDE platform)
coder groups create template-developers

coder groups edit template-developers \
  --add-permission "templates:write" \
  --add-permission "templates:read" \
  --add-permission "workspaces:read" \
  --add-permission "provisioners:read" \
  --deny-permission "users:*" \
  --deny-permission "groups:*" \
  --deny-permission "system:*"

# Assign users to the role
coder groups add-member template-developers [email protected]
coder groups add-member template-developers [email protected]

# Or sync with IdP group
coder groups sync template-developers --idp-group "Template-Devs"

Multi-Factor Authentication (MFA)

Enforce additional verification beyond passwords. MFA is required for SOC 2 Type II, HITRUST, and most compliance frameworks.

Supported MFA Methods

TOTP (Recommended)

Time-based One-Time Passwords via Google Authenticator, Authy, 1Password, etc.

WebAuthn / FIDO2

Hardware security keys (YubiKey, Titan) or biometric authentication

SMS / Push Notifications

Less secure but easier for users. Avoid for high-security environments.

Enforcement Policies

Required for All Users

Every user must enable MFA to access the platform. No exceptions.

Required for Admins Only

Enforce MFA for privileged roles (admins, platform engineers) but optional for developers.

Conditional Access

Require MFA only for risky scenarios: new device, unusual location, or after N days of inactivity.

Step-Up Authentication

Require re-authentication with MFA for sensitive actions (e.g., deleting templates, changing roles).

MFA Configuration

Option 1: IdP-Level MFA (Recommended)

When using SSO, enforce MFA at your identity provider (Okta, Azure AD, Google). This applies MFA to all applications, not just your CDE.

Okta

Security > Multifactor > Factor Enrollment Policy > Require MFA for all users

Azure AD

Security > Conditional Access > Create policy requiring MFA for all cloud apps

Google

Admin Console > Security > 2-Step Verification > Enforce for all users

Best Practice: When SSO is enabled, the CDE platform inherits MFA from your IdP. No additional configuration needed in the CDE itself.

Option 2: Platform-Level MFA

For non-SSO deployments or local admin accounts, configure MFA directly in your CDE platform.

# Example: Coder MFA configuration
# Enable TOTP for all users
coder server --mfa-required=true

# Or via environment variables
CODER_MFA_REQUIRED=true

# For specific users via CLI
coder users edit [email protected] --require-mfa=true

# Check MFA status
coder users list --format json | jq '.[] | {email, mfa_enabled}'

Session Management

Control session lifetime, token rotation, and concurrent access to prevent unauthorized persistence and credential theft.

Idle Timeout

Automatically log out users after a period of inactivity to prevent unauthorized access on unattended devices.

Recommended: 30-60 minutes for general users, 15 minutes for admins

Token Rotation

Regularly refresh authentication tokens to limit the window of opportunity if a token is compromised.

Recommended: Rotate access tokens every 1-4 hours

Concurrent Limits

Limit the number of simultaneous sessions per user to detect and prevent account sharing or compromise.

Recommended: 3-5 concurrent sessions (laptop, desktop, tablet)

Session Configuration Example

# Coder session configuration example
# Session token lifetime (how long before refresh required)
CODER_SESSION_DURATION="4h"

# Inactivity timeout (auto-logout after idle period)
CODER_SESSION_IDLE_TIMEOUT="30m"

# Maximum session lifetime (force re-authentication)
CODER_SESSION_MAX_LIFETIME="24h"

# Concurrent session limit per user
CODER_SESSION_CONCURRENT_LIMIT="5"

# Require re-authentication for sensitive actions
CODER_REQUIRE_STEP_UP_AUTH="true"

# Session persistence (remember me)
CODER_SESSION_PERSISTENT="false"  # Disable for high-security

High Security Profile

Session duration: 1-2 hours
Idle timeout: 15 minutes
Max lifetime: 8 hours
Concurrent limit: 2
Persistent sessions: disabled

Balanced Profile

Session duration: 4 hours
Idle timeout: 30-60 minutes
Max lifetime: 24 hours
Concurrent limit: 5
Persistent sessions: optional

Audit Logging for Access

Comprehensive logging of authentication events, authorization decisions, and user actions for security monitoring and compliance audits.

Critical Events to Log

Authentication Events

• Successful logins
• Failed login attempts
• Password changes
• MFA enrollment/removal
• Session created/expired

Authorization Events

• Permission granted/denied
• Role assignment changes
• Group membership changes
• Access policy updates
• Privilege escalation attempts

Resource Events

• Workspace created/deleted
• Template modified
• User provisioned/deprovisioned
• Configuration changes
• API key creation/revocation

Audit Log Format Example

Structured JSON format for machine-parseable logs, compatible with SIEM systems (Splunk, Datadog, ELK).

{
  "timestamp": "2025-11-28T14:32:15.847Z",
  "event_type": "authentication.login.success",
  "event_id": "evt_8x2a9b3c",
  "actor": {
    "user_id": "usr_alice123",
    "email": "[email protected]",
    "ip_address": "203.0.113.45",
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)..."
  },
  "resource": {
    "type": "session",
    "id": "sess_9f4e2d1a"
  },
  "context": {
    "auth_method": "oidc",
    "idp": "okta",
    "mfa_verified": true,
    "geo_location": "San Francisco, CA, US"
  },
  "severity": "info",
  "result": "success"
}

Compliance Requirements by Framework

Compliance Framework	Log Retention	Key Requirements
SOC 2 Type II	90 days minimum	All access events, changes to security controls, failed access attempts
HITRUST CSF	6 years	PHI access logs, admin actions, security incidents, log integrity verification
GDPR	Varies by use case	Data subject access, consent changes, data processing activities
PCI DSS	1 year minimum, 3 years recommended	All access to cardholder data, admin actions, authentication attempts
FedRAMP	90 days online, 1 year offline	All privileged access, security events, configuration changes, immutable logs

Log Integrity Best Practices

Use write-once storage or log forwarding to prevent tampering
Implement log signing/hashing for integrity verification
Separate log access from admin access (principle of least privilege)
Forward logs to external SIEM in real-time
Encrypt logs at rest and in transit

Platform-Specific IAM Setup

Detailed configuration guides for popular CDE platforms

Coder

Self-hosted CDE with full RBAC, OIDC, SCIM, and audit logging

OIDC/SAML SSO
SCIM 2.0 provisioning
Custom RBAC roles
Built-in audit logs
MFA via IdP

View Coder Docs

Gitpod

Container-based CDE with OAuth integration and team management

OAuth 2.0 (GitHub, GitLab, Bitbucket)
Team-based access control
SSO for Enterprise (OIDC)
Git-based permissions
Limited custom RBAC

View Gitpod Docs

GitHub Codespaces

Managed CDE with GitHub authentication and Enterprise SAML

GitHub account authentication
SAML SSO (Enterprise)
Repository-based permissions
Organization policies
No custom roles

View GitHub Docs

Need Help Choosing a Platform?

Compare Coder, Gitpod, GitHub Codespaces, Microsoft Dev Box, and Google Cloud Workstations side-by-side, including IAM capabilities.

View Tools Comparison

IAM Security Hardening Checklist

Essential security recommendations for production-grade IAM implementation

Authentication & Access

Enforce SSO: Require OIDC/SAML for all user authentication. Disable local passwords except for emergency admin accounts.
Require MFA: Enable multi-factor authentication for all users, especially admins and platform engineers.
Implement SCIM: Automate user provisioning/deprovisioning to eliminate orphaned accounts and delays.
Session Limits: Set idle timeout (30-60 min), max session lifetime (24h), and concurrent session limits (3-5).
Token Rotation: Rotate access tokens every 1-4 hours to limit exposure window.

Authorization & RBAC

Least Privilege: Grant minimum necessary permissions. Use predefined roles (Developer, Platform Engineer) instead of custom per-user permissions.
Role Separation: Separate admin, template management, and workspace access. No developer should have template edit rights.
Group-Based Access: Sync roles with IdP groups (e.g., "platform-engineers" group gets Platform Engineer role automatically).
Regular Audits: Review role assignments quarterly. Remove unused roles and orphaned permissions.
Admin Restrictions: Limit admin role to 2-3 people. Use break-glass procedures for emergency access.

Logging & Monitoring

Comprehensive Logging: Log all authentication events, authorization decisions, role changes, and privileged actions.
SIEM Integration: Forward logs to external SIEM (Splunk, Datadog, ELK) for centralized monitoring and alerting.
Retention: Retain logs per compliance requirements (90 days for SOC 2, 6 years for HITRUST).
Immutable Logs: Use write-once storage or log signing to prevent tampering. Separate log access from admin access.
Alerting: Alert on failed login spikes, admin actions, role changes, and unusual access patterns.

Compliance & Governance

Document Policies: Maintain written IAM policies, role definitions, and access procedures for auditors.
Access Reviews: Quarterly review of all user access. Require manager approval for role assignments.
Offboarding Process: Immediate access revocation on termination. Automate via SCIM or manual checklist.
Separation of Duties: Different people for development, platform engineering, and auditing. No single person with all privileges.
Compliance Mapping: Map IAM controls to compliance requirements (SOC 2, HITRUST, GDPR) for audit evidence.

Ready to Secure Your CDE?

Start with SSO and SCIM integration, then layer on RBAC, MFA, and audit logging. For compliance-critical deployments (HITRUST, SOC 2), prioritize immutable audit logs and role separation.

Compliance Guide Security Deep Dive