Open Course

Identity and Access Management Fundamentals

Identity and access management (IAM) is the set of people, processes, and technology that manages digital identities and controls their access to systems and data. It connects account lifecycles, sign-in checks, access policies, enforcement, and audit records.

itIdentity, access, and cryptography | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic — Identity and Access Management Fundamentals

Identity and access management, or IAM, is the machinery that keeps a digital identity connected to the right access and disconnected from the wrong access. It does not merely ask whether somebody knows a password. It also tracks what an account represents, which actions it may take, where that decision is enforced, and whether the access should still exist. That is a lot to ask of a login screen, which is why a login screen is not IAM.

Without this machinery, each system has to make its own decisions about accounts, sign-in, permissions, and removal. IAM gives those decisions a shared control loop: an identity source starts the record, provisioning carries it to target accounts, authentication establishes identity context, authorization evaluates a request, and review checks whether the result remains appropriate. The loop ends only when the account, credential, session, and grant reach their end states.

The first useful distinction is authentication versus authorization. Authentication shows control of an authenticator bound to an account. Authorization decides whether that authenticated subject may perform this action on this resource under these conditions. A successful sign-in is therefore not a small parade of universal permission. It is a context that still has to meet a policy.

The next distinction is federation versus provisioning. Federation carries a signed assertion or token from an identity provider to a relying application at sign-in. Provisioning creates, changes, and disables accounts and attributes over time. The surprising bit is that both can appear healthy while access is wrong: a valid sign-in can meet a stale local account, and a removed account can retain an active session. IAM is fond of such gaps because it is made of connected systems, not one very determined database.

Policies combine a subject, action, resource, and context. Roles fit stable job responsibilities. Attributes fit changing conditions such as device state or time. Relationships fit ownership and sharing. Direct grants fit bounded exceptions. Most systems mix these models, because forcing every question into one model is a fine way to turn an access rule into an archaeological site.

Least privilege then asks the annoyingly useful questions: which identity, which action, which resource, under which conditions, and for how long? The practical test is not whether a policy exists. It is whether every protected path obeys it, whether lifecycle changes reach the target, and whether audit records can explain the result.

Read the introduction for the full lifecycle and access path. Use the slides for the component map and failure boundaries. Keep the cheatsheet nearby when you need the federation checks, model comparisons, or removal checklist. The exercise turns those pieces into a decision table, where an intended permit must survive its much more interesting neighboring denials.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources