Identity and Access Management Fundamentals

4 Nov 2026, 11:2828 min readby ITYantra Admin

Complete guide to IAM fundamentals including authentication, authorization, RBAC, ABAC, federation, SSO, MFA, privileged access management, and zero trust identity.

# Identity and Access Management Fundamentals

Introduction

Identity and Access Management (IAM) is the security discipline that ensures the right individuals access the right resources at the right times for the right reasons. In modern enterprises, IAM spans on-premises directories, cloud providers, SaaS applications, and hybrid environments.

This tutorial covers IAM core concepts, authentication and authorization models, federation, SSO, MFA, privileged access management, and zero trust identity architecture. The principles apply to Microsoft Entra ID, AWS IAM, Google Cloud IAM, Okta, Keycloak, and other IAM platforms.

Learning Objectives

By the end of this tutorial, you will be able to:

Design and implement RBAC and ABAC authorization models
Configure federation and single sign-on across cloud and on-premises
Deploy multi-factor authentication and passwordless authentication
Implement privileged access management with just-in-time access
Integrate identity providers using SAML 2.0 and OpenID Connect
Apply zero trust identity principles
Audit and monitor identity events for security detection

Technical Background

IAM Core Components

| Component | Description | |-----------|-------------| | Identity | Digital representation of a user, service, or device | | Authentication | Verifying the identity of a principal | | Authorization | Determining what an authenticated principal can access | | Identity Provider (IdP) | Service that authenticates users and issues tokens | | Service Provider (SP) | Application that accepts authentication assertions | | Directory | Centralized store of identities and attributes (LDAP, AD) |

Authentication Factors

| Factor | Description | Examples | |--------|-------------|----------| | Something you know | Knowledge-based | Password, PIN, security questions | | Something you have | Possession-based | Security token, smartphone, smart card, hardware key | | Something you are | Inherence-based | Fingerprint, facial recognition, iris scan | | Somewhere you are | Location-based | IP geolocation, GPS, network segment | | Something you do | Behavior-based | Typing pattern, gesture, voice |

Authorization Models

| Model | Description | Best For | |-------|-------------|----------| | RBAC | Role-based access control; permissions assigned to roles | Most enterprise applications | | ABAC | Attribute-based access control; policies evaluate attributes | Dynamic, context-aware access | | PBAC | Policy-based access control; XACML/ALFA policies | Complex regulatory environments | | DAC | Discretionary access control; owner grants access | File systems, simple collaboration | | MAC | Mandatory access control; system enforces policy | High-security, government systems |

Identity Protocols

| Protocol | Purpose | Use Case | |----------|---------|----------| | SAML 2.0 | XML-based federation | Enterprise SSO, legacy applications | | OpenID Connect (OIDC) | OAuth 2.0 identity layer | Modern apps, mobile, SPA | | OAuth 2.0 | Delegated authorization | API access, third-party integrations | | LDAP | Directory query and authentication | On-premises directory integration | | Kerberos | Ticket-based authentication | Windows Active Directory | | WS-Federation | Microsoft federation protocol | Legacy Microsoft environments |

Prerequisites

Understanding of identity concepts (users, groups, roles)
Familiarity with cloud IAM (AWS, Azure, GCP) or directory services (AD, LDAP)
Basic knowledge of SAML, OAuth, and OIDC concepts
Understanding of authentication factors and MFA

Hardware and Software Requirements

| Component | Requirement | |-----------|-------------| | IdP | Microsoft Entra ID, Okta, Keycloak, PingIdentity, AWS IAM Identity Center | | Directory | Active Directory, OpenLDAP, FreeIPA, or cloud directory | | PAM | CyberArk, HashiCorp Boundary, Microsoft Entra PIM | | MFA | Duo, Microsoft Authenticator, Google Authenticator, YubiKey | | SIEM | For identity event logging and anomaly detection |

Step-by-Step Implementation

Phase 1: Design Identity Model

#### 1.1 Define Identity Lifecycle

Joiner: HR creates employee record → Account provisioned → Access assigned
Mover: Role change → Access reviewed and adjusted → Old access removed
Leaver: Termination → All access revoked → Account disabled → Data transferred

#### 1.2 Design RBAC Structure

Roles:
  - super-admin: Full platform access (break-glass only)
  - security-admin: Security configuration, audit log access
  - server-admin: Server management, patching, monitoring
  - db-admin: Database administration
  - developer: CI/CD, deployment, read-only production
  - auditor: Read-only access to logs and reports
  - user: Standard application access
  - guest: Limited-time, restricted access

Permissions:
  - server:read, server:write, server:delete, server:restart
  - db:read, db:write, db:admin
  - security:read, security:write
  - audit:read

#### 1.3 Role-to-Permission Matrix

| Role | server:read | server:write | db:read | security:write | audit:read | |------|-------------|--------------|---------|----------------|------------| | super-admin | ✓ | ✓ | ✓ | ✓ | ✓ | | security-admin | ✓ | - | ✓ | ✓ | ✓ | | server-admin | ✓ | ✓ | - | - | - | | db-admin | ✓ | ✓ | ✓ | - | - | | developer | ✓ | - | ✓ | - | - | | auditor | ✓ | - | ✓ | - | ✓ | | user | - | - | - | - | - | | guest | - | - | - | - | - |

Phase 2: Deploy Identity Provider

#### 2.1 Microsoft Entra ID (Azure AD)

Create tenant and configure:

1. Create Entra ID tenant (or use existing)
2. Add custom domain (ityantra.co.in)
3. Configure DNS verification (TXT/MX records)
4. Sync on-premises AD via Azure AD Connect (if hybrid)
5. Create users and groups
6. Assign licenses (Entra ID P1/P2 for advanced features)

Conditional Access policy example:

{
  "displayName": "Require MFA for all cloud apps",
  "conditions": {
    "applications": { "includeApplications": ["All"] },
    "users": { "includeGroups": ["All Users"] },
    "clientAppTypes": ["all"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  },
  "state": "enabled"
}

#### 2.2 AWS IAM Identity Center (formerly SSO)

# Enable IAM Identity Center
aws sso-admin enable-sso --instance-arn arn:aws:sso:::instance/ssoins-123456789

# Create permission set
aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-123456789 \
  --name ReadOnlyAccess \
  --session-duration PT1H

# Attach managed policy
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-123456789 \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-123456789/ps-123 \
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# Assign user to account
aws sso-admin create-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-123456789 \
  --target-id 123456789012 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-123456789/ps-123 \
  --principal-type USER \
  --principal-id <user-id>

#### 2.3 Keycloak (Self-Hosted)

# Run Keycloak via Docker
docker run -p 8080:8080 \
  -e KEYCLOAK_ADMIN=admin \
  -e KEYCLOAK_ADMIN_PASSWORD=ChangeMe! \
  quay.io/keycloak/keycloak:24.0 start-dev

# Create realm, clients, users via Admin Console or API

Phase 3: Federation and SSO

#### 3.1 SAML 2.0 Configuration

**Identity Provider (Entra ID):**

1. Add enterprise application (SAML) 2. Download SAML signing certificate 3. Configure SSO URL: `https://app.ityantra.co.in/saml/acs` 4. Configure Audience URI: `https://app.ityantra.co.in/saml/metadata` 5. Assign users and groups

**Service Provider (Application):**

SAML Settings:
  - SSO URL: https://login.microsoftonline.com/{tenant-id}/saml2
  - Entity ID: https://sts.windows.net/{tenant-id}/
  - Signing certificate: [from Entra ID]
  - Name ID format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
  - Attribute mapping: email → user.mail, name → user.displayName

#### 3.2 OpenID Connect Configuration

OIDC Provider: https://accounts.google.com or https://login.microsoftonline.com/{tenant-id}/v2.0

Application Settings:
  - Client ID: [from IdP]
  - Client Secret: [from IdP]
  - Authorization endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
  - Token endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
  - Redirect URI: https://app.ityantra.co.in/auth/callback
  - Scopes: openid profile email

#### 3.3 Just-in-Time Provisioning

Enable automatic account creation on first SSO login:

SAML Assertion Attributes:
  - user.email → mail (create account if not exists)
  - user.displayName → displayName
  - user.groups → role assignment (map group to local role)

Phase 4: Multi-Factor Authentication

#### 4.1 MFA Methods Comparison

| Method | Security | Usability | Cost | |--------|----------|-----------|------| | SMS OTP | Low (SIM swapping) | High | Low | | TOTP (Google Authenticator) | Medium | Medium | Low | | Push notification (Duo) | High | High | Medium | | FIDO2/WebAuthn (YubiKey) | Very High | Medium | Medium-High | | Certificate-based | Very High | Low | Medium |

#### 4.2 Implement TOTP MFA

# Install Google Authenticator PAM module
sudo apt install -y libpam-google-authenticator

# Generate per-user secret
google-authenticator -t -d -f -r 3 -R 30 -W

# Configure PAM (/etc/pam.d/sshd):
auth required pam_google_authenticator.so secret=/home/${USER}/.google_authenticator

# Configure SSH:
ChallengeResponseAuthentication yes

#### 4.3 Implement FIDO2/WebAuthn

Entra ID > Security > Authentication methods:
  - Enable FIDO2 security key
  - Target: All users or selected groups
  - Self-service registration: Enabled

Phase 5: Privileged Access Management

#### 5.1 Just-in-Time Access

**Microsoft Entra ID PIM:**

1. Assign eligible users to privileged roles
2. User requests activation (max 8 hours)
3. Approval workflow (optional)
4. Temporary role assignment with expiration
5. Automatic deactivation after time limit

**HashiCorp Boundary:**

# Grant temporary access to database
resource "boundary_grant" "db_access" {
  scope_id = var.boundary_scope_id
  principal_id = var.user_id
  role_id = var.developer_role_id
}

# User connects via Boundary CLI
boundary connect ssh -target-id ttcp_1234567890 -username admin

#### 5.2 Break-Glass Accounts

Emergency accounts:
  - Named: bg-admin-01, bg-admin-02
  - Password: stored in physical safe (split knowledge)
  - MFA: hardware token in sealed envelope
  - Monitoring: immediate alert on any usage
  - Review: monthly access review required

Phase 6: Zero Trust Identity

#### 6.1 Zero Trust Identity Principles

1. **Verify explicitly:** Authenticate and authorize every request using all available data points 2. **Use least-privilege access:** Limit access with just-in-time and just-enough-access 3. **Assume breach:** Minimize blast radius, segment access, verify continuously

#### 6.2 Conditional Access Policies

Policy: Require compliant device for cloud apps
Users: All users
Cloud apps: All cloud apps
Conditions:
  - Device state: Not compliant, not domain-joined
  - Client app types: Browser, mobile apps, desktop apps
Grant:
  - Require device to be marked as compliant
  - Require hybrid-joined device
Session:
  - Sign-in frequency: Every 1 hour
  - Persistent browser session: Never

Policy: Block legacy authentication
Users: All users
Cloud apps: All cloud apps
Conditions:
  - Authentication protocol: Exchange ActiveSync, IMAP4, POP3, SMTP
Grant:
  - Block access

Verification and Expected Outputs

| Check | Method | Expected Result | |-------|--------|-----------------| | RBAC enforcement | Attempt unauthorized action | Access denied | | SSO login | Access application via IdP | Seamless login, no password prompt | | MFA challenge | Login from new device | MFA prompt appears | | JIT activation | Request privileged access | Temporary access granted, expires automatically | | Access review | Quarterly review | Orphaned accounts identified and removed | | Federation | Access SaaS via corporate IdP | SAML/OIDC assertion accepted |

Troubleshooting Scenarios

| Issue | Diagnosis | Resolution | |-------|-----------|------------| | User cannot access application | Missing role assignment | Assign user to correct role/group | | SSO fails | SAML assertion mismatch | Verify attribute mapping, clock skew, certificate expiry | | MFA not prompted | Conditional Access policy not matching | Review policy conditions and grant controls | | JIT request not approved | No approver configured | Configure approval workflow or auto-approve | | Stale accounts after termination | HR not integrated with IAM | Implement HR-to-IAM provisioning | | Privilege escalation via nested groups | Group nesting too deep | Review group membership, flatten structure |

Security Best Practices

**Least privilege:** Grant minimum access required for job function
**Separation of duties:** Separate admin and user accounts; separate roles for critical operations
**Just-in-time:** Grant privileged access only when needed, for limited time
**MFA everywhere:** Require MFA for all users, especially privileged accounts
**Regular access reviews:** Review all access quarterly; remove orphaned accounts
**Passwordless:** Move toward passwordless authentication (FIDO2, certificate-based)
**Session limits:** Enforce maximum session duration and re-authentication
**Identity hygiene:** Deprovision immediately on termination; disable inactive accounts after 30 days
**Monitor anomalies:** Alert on impossible travel, new device logins, privilege escalation

Enterprise Considerations

**Hybrid identity:** Synchronize on-premises AD with cloud IdP for consistent identity
**Multi-cloud IAM:** Use cloud-native IAM plus identity federation for cross-cloud access
**Third-party access:** Provide vendor access via time-limited accounts with MFA
**Identity governance:** Implement identity lifecycle management (joiner/mover/leaver)
**Compliance mapping:** Map IAM controls to GDPR, HIPAA, PCI DSS, SOC 2 requirements
**Identity data quality:** Maintain accurate manager, department, and cost center attributes
**Break-glass procedures:** Document and test emergency access procedures quarterly

Conclusion

Identity is the new security perimeter. A robust IAM program combining RBAC, federation, MFA, privileged access management, and zero trust principles enables secure access across hybrid and multi-cloud environments. The key is balancing security with usability—too much friction drives users to circumvent controls, too little leaves the organization exposed.

Frequently Asked Questions

**Q: What is the difference between authentication and authorization?** A: Authentication verifies who you are (identity). Authorization determines what you can do (permissions).

**Q: Should I use RBAC or ABAC?** A: Use RBAC for most enterprise scenarios (simpler to manage). Use ABAC when you need dynamic, attribute-based decisions (e.g., "allow access only from corporate network during business hours").

**Q: How often should access reviews be conducted?** A: At least quarterly for all access, and monthly for privileged access.

Official Technical References

NIST SP 800-63 Digital Identity Guidelines: https://csrc.nist.gov/publications/detail/sp/800-63/final
OAuth 2.0 (RFC 6749): https://tools.ietf.org/html/rfc6749
OpenID Connect: https://openid.net/specs/openid-connect-core-1_0.html
SAML 2.0: https://docs.oasis-open.org/security/saml/v2.0/
FIDO2/WebAuthn: https://fidoalliance.org/specifications/