Consolidating Nine Identity Providers While the Mainframe Refuses to Change
Calder Industrial has 48,000 employees and 220,000 external dealer and customer identities, accumulated through acquisitions that left nine identity providers in production: two Active Directory forests, Active Directory Lightweight Directory Services, Okta, Ping, two bespoke LDAP directories, and three ADFS farms. Order entry runs on a mainframe using RACF, and finance runs on SAP ECC. Human resources is the system of record for employees, but contractor onboarding is handled by a spreadsheet emailed to the service desk. Internal audit measured an average deprovisioning time of 11 days and found 3,400 orphaned accounts, including 41 with privileged access. Sarbanes-Oxley requires demonstrable segregation of duties in SAP, where 2,100 role definitions have accumulated with no design authority. The board approved consolidation to a single identity provider within 18 months, but the mainframe team states that RACF can only accept passtickets from one trusted source and will not change before 2027. Dealers work from shared workstations in 60 branch offices, and customers increasingly expect social login with multifactor authentication.
1. Design the target identity lifecycle architecture. Where does the authoritative source sit for each population, where does provisioning orchestration sit relative to the identity provider, and how do you get orphaned accounts to a defensible level?
Read the worked answer
The most common design error here is assuming the identity provider is the lifecycle system. A single IdP answers 'who is this and can they authenticate'; it does not reliably answer 'should this person still have this entitlement in SAP and RACF'. Keep two components: one identity provider as the authentication authority, and a separate identity governance and administration layer as the entitlement lifecycle and evidence authority. Merging them is how organizations end up with a clean directory and a dirty entitlement estate.
Authoritative sources by population:
- Employees: HR system, already the SoR. Trigger joiner, mover, and leaver events from it, not from a nightly full-file comparison.
- Contractors: replace the spreadsheet with a contract-and-sponsor registry that carries a start date, an end date, a sponsoring manager, and a scope. Absent an end date, the account cannot be created. This single change addresses most of the 11-day average, because contractors are where the lag concentrates.
- Dealers: the dealer management or CRM system of record, with the dealer organization as the anchor and branch affiliation as an attribute.
- Customers: the CIAM profile store, kept deliberately separate from workforce identity, with its own credential policy and fraud telemetry.
Orchestration placement: governance layer holds the role and entitlement model, runs request and approval workflows, executes segregation-of-duties checks at assignment time, and pushes to targets via SCIM where available and connectors where not, including SAP and RACF. The IdP consumes from the same governance layer so that authentication eligibility and entitlement eligibility never diverge.
Getting orphans to a defensible level: reconcile authoritative source against every target weekly, not annually, and treat any target account without a matching authoritative record as an incident with an owner and a clock. Disable within one business day of the HR or contract event; delete at 30 days for workforce, 90 for privileged after review. The 41 privileged orphans get immediate manual review and, if unexplained, revocation with a forensic check of activity since last known legitimate use, not a quiet cleanup.
2. The mainframe will accept passtickets from exactly one trusted source until 2027, and the consolidation deadline is 18 months away. How do you architect around that, and what is your authentication strategy for legacy applications, dealers on shared workstations, and customers using social login?
Read the worked answer
Decouple the mainframe constraint from the consolidation deadline. Make the target identity provider the single trusted source for RACF, or, if the IdP migration itself cannot complete in 18 months, insert a federation gateway that presents itself to RACF as the one trusted source and federates upstream to whichever IdP is current. The gateway is a small, well-understood component, and it converts a hard 2027 dependency into a routing decision. It also gives a clean cutover path: change the upstream IdP, leave the mainframe untouched, and the mainframe team's constraint is honored without blocking the program. Document the gateway as a Tier-1 component with its own availability target, because every mainframe login now depends on it.
Legacy LDAP and ADFS applications: prefer agent-based or reverse-proxy single sign-on with the IdP over password synchronization. Password sync doubles credential exposure, breaks multifactor authentication for those applications, and leaves a second copy of the credential that survives a password reset. Where an application genuinely cannot be proxied, isolate it, restrict network access, and put it on a dated retirement list rather than accepting it as permanent.
Dealers on shared branch workstations: shared accounts are incompatible with accountability and should be eliminated, but the physical constraint is real. Design for fast user switching with a badge tap plus PIN as the primary factor, and roaming FIDO2 security keys or smartcards with PIN for step-up actions such as pricing overrides and credit approval. Session length should be short and re-authentication required for high-value operations. Do not accept a single branch account with a shared password as the target state; make the target per-user identity with a fast switch experience, and fund the hardware.
Customers with social login: social login is an identity assertion, not an authentication assurance level. Accept it for low-risk browsing and profile actions, require a Calder-issued credential or a step-up with MFA before any transaction that changes payment details, addresses, or entitlements, and bind the account to a verified contact channel to reduce takeover and account-linking fraud.
3. Choose the authorization model for the dealer portal and for SAP segregation of duties. Justify the choice against alternatives, and explain how you would enforce SoD without recreating 2,100 ad hoc roles.
Read the worked answer
Dealer portal: role plus attribute, evaluated by an externalized policy decision point. The decision inputs are inherently attributes: dealer organization, branch, territory, credit limit, product line, order value, and time of day. Pure RBAC would require a combinatorial explosion of roles across 60 branches and multiple dealer groups, which is exactly how SAP accumulated 2,100 definitions. Pure ABAC is expressive but hard for an auditor to reason about when the question is 'why could this user approve that order'. The hybrid keeps the function in a role (order entry, pricing override, credit approval) and constrains its scope with attributes. Policies live in a central decision point, are versioned in source control, and every decision is logged with the attributes and policy version used. If the dealer hierarchy becomes deep enough that relationship traversal dominates, a relationship-based model is the next step, but not before the audit story for the simpler model is proven.
SAP SoD: derive roles from a business role model, then enforce conflicting combinations as a rule set rather than as a role naming convention. Steps: define a target business role catalogue from actual job content (probably in the low hundreds, not 2,100); map each transaction code to a business activity; define the conflicting activity pairs that constitute an SoD risk (create vendor and pay vendor, create customer and release credit block, post journal and approve journal); enforce at assignment time in the governance layer, so a conflicting combination cannot be granted without a documented, time-bound mitigation approved by control owners; and run a detective review monthly on the full population, because preventive controls drift when roles are copied.
The 2,100 roles: do not cleanse them individually. Build the target catalogue, map users to target roles, run both in parallel for one cycle, compare outcomes, then cut over by user group with a freeze on new role creation. The freeze matters more than the cleanup; otherwise the catalogue is back to 2,100 within two years.