Thilan Dissanayaka Identity & Access Management May 11, 2020

Identity and Access Management (IAM)

When I was in the university we had a module called Information security. I got the chance to dive deep into varies IAM concepts. And then I joined WSO2 as a software Engineer. I realized there are much more concepts I need to get in touched. specially the modern access control methods which are not covered in the university level. I had one mission. I need to learn these in depth before I apply to the security Engineer position.

So guys, in these article series I’m going to explain the concepts I learned. I’ll begin with the basic concepts and later we can dive in to the depth of IAM.

When it comes to a protected system there are two fundamental questions to be asked at the gateway,

“Who are you, and what are you allowed to do?”

And, it’s exactly what Identity and Access Management (IAM) is built to solve.

Why??

Every day, millions of systems ask this question: Who’s trying to access me?

From logging into your company’s VPN to signing into Google or GitHub, digital identity forms the backbone of security in the modern world. Whether you’re a human, an application, or even an IoT device, your identity defines what you can access.

But here’s what most people don’t realize. Managing identity is hard. Really hard. Think about it. A modern enterprise might have thousands of employees, each needing access to dozens of internal applications, cloud services, and APIs. Some of those employees are contractors who should only have access for three months. Some are admins who need elevated privileges. Some are service accounts that machines use to talk to each other.

How do you manage all of that without losing your mind?

This is where Identity and Access Management (IAM) steps in. It’s the invisible framework that ensures the right people (and systems) get the right access, at the right time, for the right reasons.

What Is IAM?

At its core, IAM answers two fundamental questions:

1. Authentication — Are you really who you claim to be?
2. Authorization — Now that we know who you are, what can you do?

These two concepts are often confused, so let me clarify with an example.

When you walk into a hotel and show your ID at the front desk, that’s authentication — proving your identity. When they hand you a keycard that only opens your room (not other rooms, not the staff area), that’s authorization — defining what you’re allowed to access.

Together, these two pillars protect applications, APIs, and data from unauthorized access. But IAM goes far beyond just login screens. It encompasses the entire lifecycle of a digital identity from creation to deletion.

The Pillars of IAM

Let’s break IAM into its fundamental components:

Pillar	Description	Example
Identity	A digital representation of an entity (user, app, service)	[email protected], API client ID
Authentication	Process of verifying an identity	Password, OTP, biometric, certificate
Authorization	Decides what the authenticated entity can access	“Alice can read reports, not edit them.”
Provisioning	Creating, updating, and deleting user accounts	Onboarding a new employee across all systems
Governance	Monitors and audits identity usage and compliance	Access reviews, consent logs, policy enforcement

Think of IAM like a smart office security system:

• The reception desk checks your ID → Authentication
• The badge scanner decides which rooms you can enter → Authorization
• The HR system issues or revokes your access card → Provisioning
• The security logs record every entry → Governance

That’s IAM in action — digital access control for the modern enterprise.

Authentication — Proving Who You Are

Authentication is the first gate. Before a system can decide what you’re allowed to do, it needs to know who you are. And there are several ways to prove that.

Authentication Factors

Authentication methods are generally categorized into three factors:

Factor	What It Means	Examples
Something you know	Knowledge-based	Password, PIN, security questions
Something you have	Possession-based	Phone (OTP), hardware key (YubiKey), smart card
Something you are	Biometric	Fingerprint, face recognition, retina scan

Multi-Factor Authentication (MFA) combines two or more of these factors. So when GitHub asks for your password and a TOTP code from your authenticator app, that’s two-factor authentication — something you know + something you have.

Passwords Are Not Enough

We all know that people reuse passwords, write them down, and pick weak ones. I still remember, in my early days my passwords were something like qwerty or zxcvb123.

This is why modern IAM systems push for:

• Passwordless authentication — using biometrics or hardware keys instead of passwords
• Adaptive authentication — adjusting the authentication strength based on risk (e.g., new device, unusual location)
• SSO (Single Sign-On) — authenticate once, access multiple applications

How Authentication Works Under the Hood

When you log into a web application, here’s what typically happens behind the scenes:

1. User enters credentials (username + password)
2. App sends credentials to the Identity Provider (IdP)
3. IdP verifies credentials against the user store
4. If valid, IdP creates a session and issues tokens
5. App receives tokens and grants access

The tokens are the key here. In modern systems, you don’t send your password with every request — you send a token that proves you’ve already been authenticated. This is where protocols like OAuth 2.0 and OpenID Connect come into play.

A typical ID Token (from OpenID Connect) looks like this:

{
    "iss": "https://idp.example.com",
    "sub": "user-12345",
    "aud": "my-web-app",
    "exp": 1620000000,
    "iat": 1619996400,
    "name": "Alice Fernando",
    "email": "[email protected]"
}

This JWT (JSON Web Token) is digitally signed by the Identity Provider, so the application can trust it without calling the IdP again for every request.

If you want a deeper dive into how OAuth and OpenID Connect work, check out my article on OAuth: The Secret Behind “Sign in with Google”.

Authorization — Defining What You Can Do

Once you’re authenticated, the system knows who you are. Now it needs to decide what you can do. This is authorization, and it’s where things get interesting.

There are several models for making authorization decisions:

Role-Based Access Control (RBAC)

The most common approach. Users are assigned roles, and roles have permissions.

Users  →  Roles  →  Permissions

For example, in a content management system:

Role	Permissions
Admin	Create, Read, Update, Delete, Manage Users
Editor	Create, Read, Update
Viewer	Read only

This is simple, intuitive, and works well for most applications. When a new editor joins the team, you assign them the “Editor” role — done. No need to manually configure individual permissions.

Attribute-Based Access Control (ABAC)

For more complex scenarios, ABAC evaluates attributes at runtime who’s requesting, what they’re accessing, when, and from where.

A policy might say:

Allow access if user.department == "Engineering" AND resource.classification == "Internal" AND time.hour BETWEEN 9 AND 18

This gives you fine-grained, context-aware authorization that RBAC alone can’t achieve.

Implementing Authorization in Code

Here’s a simple RBAC middleware you’d commonly see in a Node.js application:

function authorize(...allowedRoles) {
    return (req, res, next) => {
        const userRole = req.user.role;

        if (!allowedRoles.includes(userRole)) {
            return res.status(403).json({
                error: "Forbidden",
                message: "You don't have permission to access this resource"
            });
        }

        next();
    };
}

// Routes with authorization
app.get("/reports", authorize("admin", "editor", "viewer"), getReports);
app.post("/reports", authorize("admin", "editor"), createReport);
app.delete("/reports/:id", authorize("admin"), deleteReport);

For a comprehensive deep dive into all access control models (DAC, MAC, RBAC, ABAC), check out my article on Access Control Models.

Federation — Trust Across Boundaries

Federation is a concept built on trusting third parties so that an identity verified by one system is accepted by another.

Without federation, every application would need its own user database, its own login page, and its own password management. Imagine creating a new account for every single website you visit. In early days this was the exactly how we used to login into different accounts on different web sites.

How Federation Works

The core idea is simple: instead of managing users yourself, you delegate authentication to a trusted Identity Provider (IdP).

User → Your App → "I don't know this user, let me ask Google"
                → Redirects to Google Login
                → User authenticates with Google
                → Google says "This is [email protected], she's legit"
                → Your app trusts Google and grants access

This trust is established through standard protocols:

Protocol	Purpose	Common Use
SAML 2.0	XML-based federation protocol	Enterprise SSO (Okta, ADFS)
OAuth 2.0	Authorization framework	API access, third-party permissions
OpenID Connect	Identity layer on top of OAuth	“Sign in with Google/GitHub/Facebook”

Single Sign-On (SSO)

SSO is a natural outcome of federation. When your company uses an Identity Provider like Okta or Azure AD, you log in once and get access to all connected applications such as Slack, Jira, GitHub, AWS Console without entering your password again.

Here’s what happens:

1. You log into your IdP in the morning
2. You open Jira — it redirects to the IdP
3. IdP sees you’re already authenticated — issues a token for Jira
4. You open Slack — same thing, no password needed
5. One login, access everywhere

This is a massive improvement for both security (fewer passwords to manage) and user experience (less friction).

User Provisioning and Lifecycle

IAM isn’t just about login and permissions. It’s about managing the entire lifecycle of a user identity.

The User Lifecycle

Create → Activate → Update → Suspend → Delete

When a new employee joins the company:

1. Provisioning — Their account is created across all necessary systems (email, Slack, GitHub, AWS)
2. Role assignment — They’re assigned appropriate roles based on their position
3. Access reviews — Periodically, their access is reviewed to ensure they still need it
4. Deprovisioning — When they leave, their access is revoked across all systems immediately

That last step is critical. If a former employee’s accounts aren’t deprovisioned promptly, you’ve got a massive security risk orphaned accounts with active credentials sitting in your systems.

SCIM — Automating Provisioning

SCIM (System for Cross-domain Identity Management) is a standard protocol for automating user provisioning. Instead of manually creating accounts in every application, the IdP pushes user data to connected apps via SCIM APIs.

POST /scim/v2/Users
Content-Type: application/json

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "userName": "[email protected]",
    "name": {
        "givenName": "Alice",
        "familyName": "Fernando"
    },
    "emails": [
        {
            "value": "[email protected]",
            "primary": true
        }
    ],
    "active": true
}

The app receives this request and creates the user automatically. When Alice leaves the company, the IdP sends a DELETE or sets "active": false, and her access is revoked everywhere instantly.

IAM in the Real World

Let’s look at how IAM is implemented in some systems you’ve probably used.

AWS IAM

If you’ve ever worked with AWS, you’ve interacted with their IAM system. AWS IAM lets you create users, groups, and roles, and attach policies that define what actions they can perform on which resources.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket",
                "arn:aws:s3:::my-bucket/*"
            ]
        }
    ]
}

This policy says: “Allow reading objects from my-bucket in S3, but nothing else.” That’s RBAC and ABAC working together. The role grants the policy, and the policy uses resource attributes to scope access.

Kubernetes RBAC

Kubernetes uses RBAC natively to control access to cluster resources:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

This creates a role that can only read pods in the production namespace. Can’t create, update, or delete them. You then bind this role to a user or service account.

WSO2 Identity Server

WSO2 Identity Server

Here is just an advertiestment guys. :) , WSO2 IS an open-source IAM platform that brings all these capabilities together in one place. It implements global identity standards and provides the building blocks for enterprise-grade IAM.

Capability	WSO2 IS Feature
Authentication	Local login, federated login (Google, Azure), adaptive MFA
Authorization	XACML-based Entitlement Engine
User Management	SCIM 2.0 APIs and user stores (LDAP, JDBC, custom)
Federation	Supports SAML 2.0, OAuth 2.0, OpenID Connect
Governance	Account locking, password policies, consent management

What makes WSO2 IS particularly powerful is its adaptive authentication. You can write authentication scripts that adjust the login flow based on context:

var onLoginRequest = function(context) {
    executeStep(1, {
        onSuccess: function(context) {
            var user = context.currentKnownSubject;
            var loginIP = context.request.ip;

            // If login is from an unknown IP, require a second factor
            if (!isWithinAllowedIPRange(loginIP)) {
                executeStep(2);
            }
        }
    });
};

This script says: “First, do normal username/password authentication. If the login comes from an unfamiliar IP, trigger a second authentication step (like TOTP).” This is adaptive MFA — adjusting security based on risk signals.

A Complete Login Flow

Here’s what happens when Alice logs into a web app integrated with WSO2 IS:

1. Alice clicks “Login” on the web app
2. The app redirects her to WSO2 IS (the Identity Provider)
3. She enters her credentials
4. WSO2 IS authenticates her (locally or via Google/Azure)
5. The adaptive script checks her login context familiar device, corporate IP.
6. WSO2 IS issues tokens (OIDC ID Token + Access Token)
7. The app validates the tokens and grants Alice access

In just seconds, IAM coordinates authentication, authorization, and federation all transparently.

Why IAM Matters

As businesses move toward the cloud, microservices, and APIs, IAM has become non-negotiable. Here’s why:

• Security — Prevent unauthorized access and data breaches. Compromised credentials are the #1 attack vector, and IAM is your first line of defense.
• Compliance — Meet standards like GDPR, HIPAA, and ISO 27001. These regulations require proper access control and audit trails.
• Efficiency — Enable centralized control, SSO, and self-service. No more manually creating accounts in 15 different systems.
• User Experience — Reduce password fatigue with federated or password-less login. Your users shouldn’t need a password manager just to get through the day.

Without IAM, every application ends up managing its own users, passwords, and permissions — a maintenance and security nightmare. I’ve seen organizations where the same user has different credentials across 20+ internal systems, with no central way to revoke access. That’s not just inconvenient. It’s dangerous.

Thanks for reading!

If you want to go deeper into the topics covered here, check out these related articles:

• OAuth: The Secret Behind “Sign in with Google”
• Access Control Models