Identity & Access Management: RBAC, ABAC, PAM & Federation - Cybersecurity Hub

← Back to Home Identity & Access Management: RBAC, ABAC, PAM & Federation Table of Contents Introduction: Identity is the New Perimeter Role-Based Access Control (RBAC) Attribute-Based Access Control (ABAC) Privileged Access Management (PAM) Identity Federation: SAML, OIDC, SCIM Just-in-Time & Zero Standing Privilege Identity Governance & Administration (IGA) Conclusion Introduction: Identity is the New Perimeter As networks dissolve into cloud, mobile, and remote work, identity becomes the primary control plane. Modern IAM is not just authentication—it's a dynamic authorization fabric that evaluates identity, device, context, and risk on every request. This guide covers the four pillars of modern IAM: RBAC for coarse-grained roles, ABAC for fine-grained dynamic policies, PAM for privileged account protection, and Federation for cross-domain identity trust. Role-Based Access Control (RBAC) RBAC assigns permissions to roles, and users inherit permissions through role membership. It's the foundation of most enterprise IAM systems. Core RBAC Model (NIST RBAC) # RBAC Components: # Users -> Roles -> Permissions -> Resources # Example: Kubernetes RBAC apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: production name: deployment-manager rules: - apiGroups: ["apps"] resources: ["deployments", "replicasets"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: deployment-manager-binding namespace: production subjects: - kind: User name: alice@example.com - kind: Group name: platform-team roleRef: kind: Role name: deployment-manager apiGroup: rbac.authorization.k8s.io RBAC Design Patterns Pattern Description Use Case Flat Roles Simple role-permission mapping Small teams, simple apps Hierarchical Roles Role inheritance (admin > developer > viewer) Enterprise, clear hierarchy Constrained RBAC Separation of duties (mutually exclusive roles) Compliance, financial systems Business RBAC Roles aligned to business functions Large orgs, business alignment RBAC Limitations Role explosion: Too many roles for fine-grained access Static: Cannot express context (time, location, risk) Coarse-grained: All-or-nothing per role Management overhead: Role lifecycle, recertification Attribute-Based Access Control (ABAC) ABAC evaluates policies against attributes of the subject, resource, action, and environment. It enables dynamic, context-aware authorization decisions. ABAC Policy Model (XACML / ALFA) # XACML Policy Structure: # # # Applicability (subject/resource/action match) # # Permit/Deny with Condition # # Boolean expression over attributes # Example ALFA (Abbreviated Language For Authorization) policy resource_access { target clause resource.type == "document" apply firstApplicable rule owner_access { permit condition subject.id == resource.owner } rule department_access { permit condition subject.department == resource.department and action == "read" and environment.time between "09:00" and "17:00" } rule deny_all { deny } } ABAC Attribute Categories Category Examples Source Subject user.id, role, department, clearance, device.id, device.compliance IdP, MDM, HR Resource type, owner, classification, tags, location, sensitivity CMDB, DLP, Resource tags Action read, write, delete, execute, share, approve Application Environment time, location, network, risk_score, threat_level SIEM, Threat Intel, GeoIP OPA/Rego for ABAC # Open Policy Agent with Rego for ABAC package abac.document default allow = false # Allow if owner allow { input.subject.id == input.resource.owner } # Allow if same department and business hours allow { input.subject.department == input.resource.department input.action == "read" business_hours } # Allow if manager of resource owner allow { input.action == "approve" is_manager(input.subject, input.resource.owner) } business_hours { hour := input.environment.time.hour hour >= 9 hour <= 17 input.environment.time.weekday < 6 } is_manager(subject, owner) { m := data.hr.managers[owner] m == subject.id } # Decision API: # POST /v1/data/abac/document/allow # { "input": { "subject": {...}, "resource": {...}, "action": "read", "environment": {...} } } AWS ABAC with Tags # AWS IAM policies using principal/resource tags { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "*", "Condition": { "StringEquals": { "ec2:ResourceTag/Environment": "${aws:PrincipalTag/Environment}", "ec2:ResourceTag/Owner": "${aws:PrincipalTag/EmployeeID}" } } }] } # Tag users with: Environment=Production, EmployeeID=12345 # Tag EC2 instances with same tags # Policy automatically grants access to matching resources Privileged Access Management (PAM) PAM secures, manages, and monitors privileged accounts (admin, root, service accounts) that have elevated permissions. PAM Core Capabilities Capability Description Examples Credential Vaulting Store, rotate, inject secrets CyberArk, HashiCorp Vault, Thycotic Session Management Record, monitor, replay sessions PSM, RDP/SSH proxy, keystroke logging Just-in-Time Access Elevate on-demand, auto-revoke PIM, PIM for Groups, JIT SSH Least Privilege Command allow-listing, sudo policies sudoers, CyberArk EPM, BeyondTrust Analytics Anomalous behavior, risk scoring UEBA, session anomaly detection PAM Implementation Patterns 1. Vault + Rotation # HashiCorp Vault for database credentials # Database secrets engine with dynamic credentials # Configure database connection vault write database/config/my-postgres \ plugin_name=postgresql-database-plugin \ connection_url="postgresql://{{username}}:{{password}}@db:5432/mydb" \ allowed_roles="readonly" \ username="vault_admin" \ password="static_admin_password" # Create role with TTL vault write database/roles/readonly \ db_name=my-postgres \ creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \ default_ttl="1h" \ max_ttl="24h" # Application requests credentials # vault read database/creds/readonly # Returns: username="v-token-xxx", password="dynamic", lease_id="database/creds/readonly/xyz", lease_duration=3600 2. Just-in-Time Elevation (Azure PIM Example) # Azure AD Privileged Identity Management # 1. Make users "Eligible" for role (not permanently assigned) # 2. User activates role when needed # 3. Requires MFA, justification, approval, ticket number # 4. Time-bound (1-8 hours typically) # 5. Automatic revocation, audit trail # PowerShell to configure PIM # Connect-AzureAD # $role = Get-AzureADMSRoleDefinition -Filter "DisplayName eq 'Global Administrator'" # $schedule = New-Object Microsoft.Open.MSGraph.Model.AzureADMSPrivilegedSchedule # $schedule.Type = "Once" # $schedule.StartDateTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ssZ") # $schedule.EndDateTime = (Get-Date).AddHours(8).ToString("yyyy-MM-ddTHH:mm:ssZ") # Open-AzureADMSPrivilegedRoleAssignmentRequest ` # -ProviderId "aadRoles" ` # -ResourceId "tenant-id" ` # -RoleDefinitionId $role.Id ` # -SubjectId "user-object-id" ` # -Type "UserAdd" ` # -AssignmentState "Eligible" ` # -Schedule $schedule ` # -Reason "Quarterly access review" 3. SSH Certificate-Based Access # Smallstep / HashiCorp Vault SSH certificates # No long-lived SSH keys - short-lived certificates # Server side: Trust CA public key # /etc/ssh/sshd_config: # TrustedUserCAKeys /etc/ssh/ca.pub # AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u # Client requests certificate # step ssh certificate --provisioner=ssh-ca user@host --valid=1h # Certificate contains: # - Key ID (user identity) # - Principals (allowed usernames) # - Extensions (force-command, source-address) # - Validity (short TTL: 5min - 1h) # Audit: SSH logs show certificate Key ID for every session Identity Federation: SAML, OIDC, SCIM Federation enables identity portability across security domains—employees, partners, customers using their home identity provider. SAML 2.0 (Enterprise SSO) # SAML Flow: SP-Initiated # 1. User accesses SP (service provider) app # 2. SP redirects to IdP with SAML AuthnRequest # 3. User authenticates at IdP # 4. IdP posts SAML Response (with Assertion) to SP ACS URL # 5. SP validates signature, extracts attributes, creates session # SAML Assertion (simplified) https://idp.example.com ... user@example.com https://sp.example.com/metadata engineering platform-team Engineering OpenID Connect (Modern, API-First) # OIDC Flow: Authorization Code + PKCE (for SPAs/native apps) # 1. Client redirects to /authorize with code_challenge (PKCE) # 2. User authenticates at IdP # 3. IdP redirects back with authorization code # 4. Client exchanges code for tokens at /token (with code_verifier) # 5. IdP returns: access_token, id_token, refresh_token # OIDC Discovery # GET https://idp.example.com/.well-known/openid-configuration { "issuer": "https://idp.example.com", "authorization_endpoint": "https://idp.example.com/authorize", "token_endpoint": "https://idp.example.com/token", "jwks_uri": "https://idp.example.com/jwks", "scopes_supported": ["openid", "profile", "email", "groups", "offline_access"], "response_types_supported": ["code", "code id_token"], "subject_types_supported": ["public", "pairwise"] } # ID Token (JWT) Claims { "iss": "https://idp.example.com", "sub": "user-12345", "aud": "client-id", "exp": 1704123456, "iat": 1704119856, "auth_time": 1704119800, "email": "user@example.com", "email_verified": true, "groups": ["engineering", "platform-team"], "preferred_username": "user" } SCIM 2.0 (Provisioning) # System for Cross-domain Identity Management # Automates user/group lifecycle: create, read, update, delete (CRUD) # SCIM Endpoints # GET /Users?filter=userName eq "user@example.com" # POST /Users # GET /Users/{id} # PATCH /Users/{id} # DELETE /Users/{id} # GET /Groups # Create User Request POST /Users { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "userName": "user@example.com", "name": { "formatted": "John Doe", "givenName": "John", "familyName": "Doe" }, "emails": [{"value": "user@example.com", "primary": true, "type": "work"}], "groups": [{"value": "group-id-1", "display": "engineering"}], "active": true } # Provisioning Flow: # IdP (Okta/Entra) -> SCIM Client -> SCIM Server (App) -> App User Store # Real-time or scheduled sync Federation Protocol Comparison Aspect SAML 2.0 OIDC / OAuth 2.0 SCIM 2.0 Primary Use Enterprise SSO Authentication + API Authorization Identity Provisioning Token Format XML Assertion JWT JSON Browser/Client POST Binding (form submit) Redirect + PKCE Server-to-Server (REST) Session Mgmt SAML SLO (limited) OIDC RP-Initiated Logout, Front/Back-channel N/A API Access No Yes (Access Tokens) Yes (Admin API) Complexity High (XML, signatures) Moderate (JWT, JWKS) Low (REST + JSON) Just-in-Time & Zero Standing Privilege Zero Standing Privilege (ZSP) means no user has persistent elevated access. All privileged access is granted just-in-time, time-bound, and fully audited. ZSP Architecture # ZSP Request Flow: # 1. User requests access via chat/portal/API (Slack, Teams, Jira, CLI) # 2. Policy engine evaluates: role, justification, risk, approvals # 3. If approved: short-lived credential issued (cert, token, SSH key) # 4. User performs task # 5. Credential auto-expires, session recorded, audit logged # Example: Teleport (SSH/K8s/DB/App access) # Teleport Auth Server issues short-lived certificates # tsh login --proxy=teleport.example.com --user=alice # tsh kube login production-cluster # tsh db login production-postgres # All access: MFA required, time-bound (1h default), recorded, auditable # No standing SSH keys, no standing kubeconfig, no standing DB passwords Risk-Based Adaptive Access # Continuous risk evaluation during session # Factors: # - Device posture (MDM compliant, EDR running, patch level) # - Network (corporate, VPN, public WiFi, Tor, high-risk geo) # - Behavior (impossible travel, velocity, new device, anomalous commands) # - Threat intel (IP reputation, credential leak, malware signals) # Response actions: # - Low risk: Allow # - Medium risk: Step-up auth (MFA, device approval) # - High risk: Require manager approval, restrict commands # - Critical risk: Terminate session, alert SOC, lock account # Example: Okta Adaptive MFA / Azure Conditional Access / Duo Trust Monitor Identity Governance & Administration (IGA) IGA provides the lifecycle management, compliance, and oversight layer for identity. IGA Core Processes Process Description Frequency Joiner/Mover/Leaver Automated provisioning/deprovisioning from HR source Real-time / Daily Access Certification Managers review and certify user access Quarterly / Semi-annual Role Mining Discover roles from existing access patterns Annual / On-demand Segregation of Duties Detect toxic role combinations Continuous / Pre-deployment Orphan Account Detection Find accounts without owners Monthly Access Review Automation # Example: Automated certification campaign # 1. Generate review items: all user-role assignments # 2. Send to reviewers (managers, app owners) # 3. Reviewers: Certify / Revoke / Escalate # 4. Auto-remediate: revoke uncertified after deadline # 5. Evidence: signed attestation for auditors # SailPoint / Saviynt / Omada / Azure AD Access Reviews # Azure AD Access Review example: # POST /accessReviews/definitions { "displayName": "Quarterly Admin Access Review", "scope": { "@odata.type": "#microsoft.graph.accessReviewScope", "query": "/roleManagement/directory/roleAssignments?$filter=roleDefinitionId eq 'GlobalAdmin'" }, "reviewers": [{"query": "/users/{managerId}", "queryType": "MicrosoftGraph"}], "settings": { "mailNotificationsEnabled": true, "reminderNotificationsEnabled": true, "justificationRequiredOnApproval": true, "defaultDecision": "Deny", "instanceDurationInDays": 14, "autoApplyDecisionsEnabled": true } } Conclusion Modern IAM is a layered architecture: RBAC provides the baseline structure, ABAC adds dynamic context-aware decisions, PAM protects the most sensitive accounts, Federation extends identity across boundaries, and IGA ensures governance and compliance. The trajectory is clear: Zero Standing Privilege replaces persistent admin rights, Continuous Verification replaces one-time authentication, and Policy-as-Code replaces manual configuration. Organizations that treat identity as infrastructure—version-controll