IAM Chapter 7, Part 2: Out and Back

Part of the IAM study series.

Part 1 decided what John should have. This part is everything that makes it actually happen, and the controls that catch it when it doesn't.

1. Push or Pull

A connector is integration code that knows how to talk to one target system, and a target system is any app the platform provisions into. Provisioning runs in two directions:

JIT solves the joiner elegantly and does nothing for the leaver. The account appears by itself and never goes away by itself, so an estate leaning on it gets a great day one and a very large orphan problem.

Don't confuse the two meanings of JIT. JIT provisioning creates an account at first login. JIT access, from Chapter 6, is a grant that expires on its own.

2. The Integration Tiers

From most to least automated: SCIM, the vendor's native API, LDAP/AD (fine where the app genuinely reads AD), database writes (fragile and unsupported), file drops (batch, no acknowledgement), and manual, a ticket to a human.

The bottom rung deserves defending. For the long tail not worth a connector, the right answer is a generated ticket with precise instructions, tracked to closure, with the entitlement recorded in the catalogue. It's slow, but the request was approved, the grant is recorded, and it will appear in recertification. That's far better than the real alternative: an email to an admin that nobody ever sees again.

Batch or event-driven? A nightly batch is simple, but a leaver keeps access until morning. Events fire immediately, but have more moving parts and fail for one person silently. Most estates run events for leavers and batch for everything else.

Whichever you pick, two things decide whether any of it works:

• Operations must be idempotent. Running "add John to PLM Wing Engineer" twice must do nothing the second time. Without that you can't safely retry, and every transient failure becomes permanent.
• Failures must be loud. The classic disaster isn't a connector that breaks, but one that breaks quietly: the platform believes 2,000 people have correct access, while one target has been rejecting writes for five weeks. Every connector needs retry, alerting, and reconciliation.

The metric that matters is percentage of entitlements under management, not applications integrated. You can integrate 60 apps and cover 25% of entitlements, because the other 140 include the ones everybody uses.

3. SCIM: One Plug Instead of 200

SCIM (System for Cross-domain Identity Management) is an IETF standard for provisioning identities over REST: RFC 7643 is the schema, RFC 7644 the protocol. SCIM is to provisioning what LDAP is to reading. Instead of a bespoke connector per vendor, you build one integration for every app that speaks it.

John's whole life in Slack is three calls:

2 Nov   POST /Users
        { "userName": "john.wick@...", "active": true,
          "employeeNumber": "884213", "department": "Wing Assembly" }
 
1 Mar   PATCH /Users/{id}
        { "department": "Stress Analysis" }
 
30 Jun  PATCH /Users/{id}
        { "active": false }     ← not DELETE

employeeNumber is the correlation key from Part 1, travelling in the standard enterprise extension. active: false is how you disable, so the disable-then-delete pattern is built into the protocol. Your IGA or Entra ID is the client, and the app is the service provider. That term meant something specific in SAML; here it only means the app being provisioned into.

SCIM is good, but it's not the end of the connector problem:

• It barely covers entitlements. Users and groups work well, but roles, licence types, and permissions inside the app are vendor extensions or nothing.
• "SCIM-compliant" means very little. Some implementations ignore most of the payload, PATCH support is notoriously inconsistent, and group push is the usual sore point. You find this out during integration, not from the datasheet.
• It's one-directional. An app has no standard way to tell you something changed, so an admin can create an account directly and SCIM will never mention it.

4. Reconciliation: The Only Control That Looks the Other Way

Everything so far pushed intent outward. This is the only step that reads reality back in. The platform compares what it believes with what the target actually has:

"Missing" is how a silently broken connector gets caught, and nothing else would find it. The whole control depends on the correlation key: reading a target gives you a list of accounts, and every useful question starts with "whose is this?" Without the key, every account looks like an orphan.

It's not optional either. Failures that grant too much access are silent, so nobody will ever tell you. Reconciliation is the looking.

What to do with findings. Auto-remediation is correct in principle but dangerous while the catalogue is incomplete: you'll revoke legitimate access, and the escalation will stop the programme. Most estates flag entitlements for review and auto-remediate a narrow, confident set, typically disabled accounts that are still enabled.

Budget for the first run. It produces an enormous number of findings, mostly data quality rather than security: naming inconsistencies, test accounts, and shared accounts nobody documented. Treat that output as a security incident and the team burns out in a fortnight. Treat it as a cleanup backlog triaged by risk, and you'll get through it.

Reconciliation also makes recertification meaningful. Asking an owner to confirm "what this person has" is only worth doing if the list is true.

What Breaks in Practice

🔴 CHECKPOINT: Study Notes

← Previous: The Badge Office · Back to the series start · Next: Nobody to Ask →