Skip to main content

SAP-Managed IAM Integration

Last updated on by sapgunnar

In the SAP-managed integration model, SAP operates the IAM integration between SAP solutions as part of a managed experience. The customer continues to federate its users to SAP Cloud Identity Services, but the trust, provisioning, and authorization wiring that connects the SAP solutions to each other is pre-configured and operated by SAP.

This model is what makes cross-application SAP experiences possible — SAP Task Center, SAP Joule, and the agentic capabilities of the SAP Business AI Platform. These experiences require a trusted, consistently available, single identity interface in the landscape with a known set of features. Without SAP Cloud Identity Services as that interface, they could not be offered.

Architecture​

image of solution diagram
Copy to clipboard
Solution Diagram Resources
You can download the Solution Diagram as a .drawio file for offline use. Alternatively, you may view and edit the Solution Diagram directly on draw.io.
Please note that any changes made online will need to be saved locally if you wish to keep them.
DownloadEdit

Three Maturity Stages​

SAP-managed integration is not a single switch — it is a progression. As more SAP solutions are consolidated under a shared identity, the experience becomes more unified and SAP Cloud Identity Services takes on an increasingly leading role. We describe three stages:

  1. Line-of-Business–Scoped Experience — The SAP-managed experience is scoped to an individual line-of-business application. Each application keeps its own users, but those users are consolidatable: their cached records in the Identity Directory can later be linked under a common Global User ID for cross-application correlation. This is the natural entry point for customers adopting a managed experience such as Joule application-by-application.

  2. Unified Experience, Application IAM Leading — A single, unified experience now spans multiple SAP applications, but the individual applications' IAM remains the authority for identities and authorizations. SAP Cloud Identity Services unifies authentication and the engagement layer without yet owning the lead for identity data. The experience is unified; the system of record is still distributed across applications.

  3. SAP Cloud Identity Services Centrally Leading — SAP Cloud Identity Services becomes the central leading system for identities and for authorization assignment across the SAP solutions. Applications consume identities and policy assignments from the Identity Directory rather than acting as independent sources. This is the target end-state, exemplified by the ERP SaaS Suite, and it aligns with the consolidated landscape in the Joule Landscape Recommendation.

Together these stages describe a migration path: from scoped and consolidatable, through unified-but-distributed, to centrally led.

Landscape Recommendation​

The Joule Landscape Recommendation applies the SAP-managed model to a concrete setup, showing how SAP Cloud Identity Services and the SAP Business AI Platform are organized across staged and consolidated landscapes.

Coexistence with an Existing Customer IDM​

Adopting the SAP-managed model does not require re-engineering an existing identity landscape. Processes already running against SAP Cloud Identity Services continue to run unchanged. The customer's own Identity Management (IDM) solution remains the system of record for its people — who employees are, how they join/move/leave, and which access they receive — and the SAP-managed provisioning coexists in the same SCI tenant alongside those processes without colliding with, overwriting, or disturbing the objects the customer's IDM already governs.

User groups vs. application groups — the main concern​

A frequent question when SAP-managed provisioning is introduced is what happens to the groups a customer already maintains. The distinction between two kinds of groups in SAP Cloud Identity Services is central:

  • IAS user groups (commonly used). It is common for customers to drive user groups in SAP Cloud Identity Services from their IDM, typically following a name-pattern convention. These groups are IDM-owned and stay fully under customer control.
  • Application groups (less commonly used). Application groups express entitlements for Authorization Management (AMS) and are what the SAP Business AI Platform needs to build the complete user → (role →) authorization picture. These are less commonly used by customers today, and in the SAP-managed model they are the groups SAP replicates and maintains (SAP-managed), so the platform always has current authorization data without customer effort.

The main concern — that an SAP-managed provisioning job writing into SCI would interfere with the customer's existing IDM-owned groups and processes — is addressed by an explicit ownership boundary enforced at the Cloud Identity API (IdDS/SCIM) level:

  • The customer IDM technical user shouldn't manipulate SAP-managed (application) groups in the stages where Cloud Identity is not leading.
  • The SAP-managed provisioning technical user will not manipulate IDM-owned groups, and on user objects it may update only link/correlation attributes — never the customer's IDM-owned lifecycle attributes or group memberships.
  • For the stage with Cloud Identity as leading entity for the business application each SAP-managed group is defined by the application and all attributes except "members" are immutable for the external IDM — while membership assignments remain mutable, so the customer can add or remove members as the business requires in such a scenario.

This separation of responsibilities means the customer keeps every control it has today, gains a clearly auditable split of ownership, and can go live without changing its side. Over time, the model opens up more choice — moving to the suite approach on a per-application basis, where the customer's IDM can progressively take over membership of the SAP-managed application groups, application by application.

Extending to AI Agents​

The SAP-managed model is the foundation for identity of autonomous AI actors. The Agent Identity reference architecture extends SAP-managed IAM to AI agents: SAP Cloud Identity Services stores agent identities alongside human identities, and the SAP Agent Gateway enforces policy at every communication hop. Agent Identity is best understood as the agentic continuation of this SAP-managed integration story.

Characteristics​

  • SAP operates the IAM integration between SAP solutions; the customer federates to SAP Cloud Identity Services and consumes the managed experience.
  • A shared Global User ID in the Identity Directory makes users consolidatable across applications from the earliest stage.
  • The model matures from line-of-business scope toward SAP Cloud Identity Services as the central leading system.
  • It is the identity foundation for unified experiences (Joule, Task Center) and for agent identity.

Services and Components​