IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Identity governance — requests, roles and separation of duties
Provisioning gives access to people. Governance makes sure it is the right access. It has a reason, an accountable approver, and no dangerous mix of rights. Your goal: design an approval flow that catches risky pairs of rights.
- Birthright access is automatic. Everything else is requested and approved.
- Give approvers context, or they just click Approve.
- Role mining shows what people hold, not what a job needs.
- Separation of duties blocks risky pairs of rights, and scans for them later.
What governance adds
IGA means identity governance and administration. It answers three questions that auditors ask about every grant. Who has this access? Who approved it? Is it still right?
SCIM provisioning creates and removes accounts. IGA decides what those accounts may do, and keeps a record of why.
Birthright access and requested access
Birthright access is what you get automatically, by policy, for being who you are. Every shop employee gets the roster app. It follows attributes such as department or job. It needs no ticket. The lifecycle lesson introduced it.
Everything else should be requested, explained and approved. It should also expire when possible. Special cases tied to one person belong here.
Birthright grants are cheap, so put routine, safe access there. Requested grants cost an approver's attention, so save them for access that needs a decision.
If approvers see only a bare code, they approve all 20 requests. This is the rubber-stamp problem. Show a description, the risk, and the requester's other access. Send the request to the resource owner too. They know what the access exposes. A second signer with no extra context adds nothing.
Where roles come from
Roles are bundles of access for a job. Role engineering works top-down, from what the business says a job needs. Role mining works bottom-up, from the access people hold today.
Mining has a trap. It shows what people hold, not what the job needs. If the directory is full of extra access, the mined role locks that in. A human owner must confirm each right belongs before a bundle becomes a role. Never make one custom role per person.
Separation of duties
SoD means separation of duties. No one person should hold powers that let them commit and hide fraud alone. A forbidden pair of powers is a toxic combination.
A bank branch. One clerk enters a big transfer. A different officer approves it. Banks call them the maker and the checker, and the same person is never both. SoD is that rule, for every risky pair of rights.
The classic pair: create a vendor, and approve payments to vendors. With both, a person could invent a fake supplier and pay it. Enforce SoD in two ways, and use both:
🛑 Preventive
Block the risky grant when it is requested. Priya moved to Finance Operations but still holds "create vendor." So the system refuses "approve payment," or forces a logged exception. Once her manager removes the old right, the grant goes through. This is a preventive control.
🔍 Detective
On a schedule, scan the access people hold now. Expand every role into its rights. Flag anyone with a risky pair. A grant that expires later still counts today. A request not yet granted does not count. This is a detective control.
SoD rules are only as good as the entitlements they check. If one coarse role secretly holds both rights, a rule that looks for two separate grants never fires. Design entitlements fine enough to tell risky powers apart.
Go deeper: The entitlement catalog and friends
An entitlement catalog
A browsable list of every entitlement people can hold or ask for. An entitlement is one specific permission, group membership or app role. Each has a plain description and an owner.
Request & approval
A flow to ask for access and send it to the right approvers. It leaves an audit trail, instead of a chat message nobody can find later.
Roles
Bundles of entitlements that match a job. People get a sensible base without picking dozens of permissions by hand.
Policy & controls
Rules that catch dangerous pairs of rights, plus the regular access reviews that re-check reality over time.
Open-source IGA platforms exist too. One example is midPoint, released under the European Union Public License. None of this needs a closed product.
Go deeper: Approval workflows: who should say yes
If only the requester approves, it is theater. Good flows send the request to people who know:
- The requester's manager, who knows whether the job needs it.
- The resource owner, who is accountable for the app and knows what the access exposes.
- For sensitive access, both in order, so two independent people sign.
The same trap from access reviews appears here. Give a person 20 requests with bare entitlement names, and they will approve all 20. Add rich context: a description, the requester's other access, the risk level. That turns a stamp into a decision. Reviews catch bad grants after the fact. Approvals stop them earlier and cheaper, before the access exists.
Go deeper: Top-down roles and bottom-up role mining
| Top-down (role engineering) | Bottom-up (role mining) | |
|---|---|---|
| Starts from | The business: job descriptions and tasks | The data: what access people hold today |
| Method | Ask the business "what should a Store Manager have?" | Look for groups of people who hold the same access |
| Strength | Roles match how the business thinks | Shows real patterns that people miss |
| Weakness | Slow, and can miss what people really use | Copies today's mistakes and over-grants as if they were right |
If you mine roles from a directory full of entitlement creep, you build roles that lock the creep in. Mining suggests roles. A human must still ask whether each bundle should exist. Aim for a small set of roles that fits most people, plus a birthright base. Request the unusual access on top. One custom role per person is just per-user permissions in a costume.
Go deeper: More toxic pairs, and static and dynamic SoD
NIST SP 800-192 states SoD simply: no user should have enough privileges to misuse the system alone. SoD is also called segregation of duties. Other pairs: create a user and grant access to that user. Submit an expense and approve it. Write code and deploy it to production unchecked.
NIST describes two ways to enforce SoD. Static SoD defines roles that no one person may hold together. You check it when you assign access. Dynamic SoD checks at the moment of action. An example is a two-person rule: the second approver must differ from the first.
Companies usually put static rules in the entitlement model and use dynamic rules for the most sensitive single actions. Source: NIST glossary entry for separation of duty (from SP 800-192).
An audit asks: was every sensitive grant approved, free of toxic pairs, and re-checked over time? The higher the privilege, the more a toxic pair costs. See the most powerful access next.
🧪 Interactive lab — enable JavaScript to play with this one.
Run the open-source midPoint in Docker (its quickstart takes minutes). See how it defines roles, requests and rules. Then read its governance and compliance pages.