Cloud Security Engineer

Role Engineering for IGA migration: How it is performed from scratch?

During my SOC co-op, I spent a couple of days on the identity side instead of alerts. The organization migrated its IGA platform, and a big part of that migration is role engineering which consist of deciding what roles exist, what entitlements live inside each role, and who signs off on it. My job was to help the managers who had not finished their staff's role access review get through it.

Problem

Flow diagram of the identity provisioning architecture. PeopleSoft, the HR source of truth, adds or removes accounts in SailPoint ISC. Role add, delete, and modify requests also come into SailPoint ISC. SailPoint controls the entitlements in Active Directory, which fans out to Entra, SaaS apps, and accounts.
PeopleSoft (HR) → SailPoint ISC → Active Directory → Entra, SaaS apps, accounts

The IGA sits above Active Directory and controls it, because AD itself cannot manage complex access controls or automate roles. With plain AD you assign groups to a person one by one. With IGA you assign one role, and the role carries the groups.

Why can't we manually assign it?

As an organization scales, access management becomes complex. More users means more groups, and that makes access difficult to audit and costly to maintain. Assigning groups one by one works when the company is small.

How roles are built

Line of Business: The access required to make the business value, basically your work requirement

  1. Birthright access (ex. Base Employee). Every user gets the baseline tools required to operate within the organization.
  2. LOB Base Roles (ex. Finance - All). Baseline access required for all users within a specific line of business.
  3. LOB + Business Function (ex. Finance - Payroll - Analyst). LOB plus job code, giving business function specific access within the LOB.
  4. LOB + Business Function + Department (ex. Payroll Analyst - North America). LOB plus job code plus department, the most specific tier.

Why do we need to design like this?

  • It creates a clear access hierarchy that lines up with how the business operates
  • It prevents role explosion, simplifies access reviews, and makes access easier for the business to understand
  • Controls can be enforced per tier, like approval workflows, periodic recertification of roles, and analytics and reporting
  • It connects to the identity lifecycle (joiner, mover, leaver), so roles can be automated through HR attributes

IAM Admin interaction with different roles

  • IAM SME: liaise and collaborate to provide advice and guidance, and carry that knowledge into the business unit
  • SoD Policy Owner: where required, validate and submit requests on behalf of the SoD policy owner
  • Role Owner: where required, validate and submit requests on behalf of the role owner
  • Users: validate the inputs and requirements gathered from users, then capture, log, and direct their requests
  • IAM Governance and Advisory: participate and contribute to the IAM community of practice

Gap Report / Validated Role Model

The gap report is the document managers review then it becomes the Validated Role Model when they approve

List of things to review

  • Entitlement name, which is the permission group, not the role manager
  • Entitlement description, holding the permission group owner
  • Entitlement attributes: memberOf, groups, roles, name, permissions, and so on
  • Application, the type of application the entitlement lives in, like Active Directory
  • % popularity, the percentage of people who have the entitlement within the same role, department, or group
  • Included identities, the staff who have the entitlement within the role
  • Missing identities, the staff who do not have the entitlement within the role

Who should own the role and control its entitlements?

It's the role's reporting manager.

RBAC role engineering process

Gap Report

The document that says what should happen in the target state, what gaps exist (missing data, messy entitlements, lack of approvals, etc), and what needs to be fixed, with recommendations and priority. The role engineering team reviews it.

Validated Role Model

This is where the business accepts that this entitlement belongs in this role, and we accept the risk. This step also classifies what is automatic versus what requires approval, and the rule of thumb is % population, generally 80-100%. The corresponding manager reviews it.

Validated Business Scenarios

A migration can fail in quiet ways. Provisioning does not happen correctly, approvals route to the wrong people, terminations do not remove access, certifications do not revoke access. Validated business scenarios are real life workflows that prove the new IGA group works. The IGA team, the app owner, SOC and operations, and the auditors, GRC all review these.