Security & GRCarchitect

Cloud Identity Architecture: Corporate IdP, BTP, SaaS Apps and Provisioning Governance

Key takeaway

Design a hybrid SAP identity architecture with one authoritative workforce identity, federated authentication, controlled provisioning and consistent role mapping across BTP and SAP SaaS.

Explanation

📌 KEY POINTS
✅ One authoritative source for workforce lifecycle (usually HR/identity governance) — not one source per application.
⚠️ Every custom point-to-point provisioning connection increases mapping and deprovisioning risk.
💡 Technical users and service principals need a different lifecycle from workforce users — don't run them through normal joiner/mover/leaver logic.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE ARCHITECTURE

Corporate IdP authenticates → SAP Cloud Identity Services federates → provisioning distributes users/groups to targets

━━━━━━━━━━━━━━━━━━━━
⚠️ 2. AVOID IDENTITY SPRAWL

Every custom provisioning connection = more mapping and deprovisioning risk
Use standardized SCIM-based or SAP-supported connectors where available

━━━━━━━━━━━━━━━━━━━━
▶ 3. ROLE MAPPING DISCIPLINE

Separate identity groups from application roles
A corporate group may map to BTP role collections or SaaS permissions — but that mapping must be governed and reviewed

━━━━━━━━━━━━━━━━━━━━
▶ 4. TECHNICAL USERS ARE DIFFERENT

Service principals need explicit ownership, not default employee joiner/mover/leaver logic

━━━━━━━━━━━━━━━━━━━━
▶ 5. WHAT ARCHITECTURE MUST COVER

Certificate/secret rotation, tenant lifecycle, break-glass access, monitoring failed deprovisioning (orphaned access is the major risk)

✅ CHECKPOINT: explain why technical/service users shouldn't follow the same lifecycle as employees.

Real project scenario

A terminated contractor was disabled in the corporate directory but remained active in one SaaS tenant because its custom provisioning job had failed for weeks. Central provisioning monitoring exposed the orphaned-access gap.

Common mistakes

Direct provisioning from many sources to many targets.
Mapping broad groups to admin roles.
Treating service identities like employees.
Monitoring provisioning only, not deprovisioning.
Ignoring certificate and tenant lifecycle.

Best practices

Use one authoritative lifecycle source.
Standardize provisioning paths.
Govern group-to-role mappings.
Monitor removal failures.
Separate service-identity governance.

Interview angle

Design identity flow from HR/corporate IdP to SAP cloud applications and explain authentication versus provisioning versus role mapping.

Practice this lesson

Quick check

1. Scenario — A terminated contractor was disabled in the corporate directory but remained active in one SaaS tenant because its custom provisioning job had failed for weeks. Which response best addresses the design or operating risk in Cloud Identity Architecture: Corporate IdP, BTP, SaaS Apps and Provisioning Governance?

2. A review of Cloud Identity Architecture: Corporate IdP, BTP, SaaS Apps and Provisioning Governance finds this risky pattern: "Provisioning every group to every target.". Which corrective action is strongest?

3. Design a hybrid SAP identity architecture with one authoritative workforce identity, federated authentication, controlled provisioning and consistent role mapping across BTP and SAP SaaS. A production team now has to make a design decision in Cloud Identity Architecture: Corporate IdP, BTP, SaaS Apps and Provisioning Governance. Which option best preserves reliability and supportability?

Interview questions

1. A project team is working on SAP Cloud Identity Services. Using the Cloud Identity Architecture: Corporate IdP, BTP, SaaS Apps and Provisioning Governance scenario, how would you approach the requirement from design through validation?

Answer it in your own words first, then compare.

2. What design decisions and trade-offs matter most when implementing SAP Cloud Identity Services, particularly for Cloud Identity Architecture: Corporate IdP, BTP, SaaS Apps and Provisioning Governance?