SAP Business Technology Platform (BTP) is undergoing a fundamental shift in how identity and authorization management is handled. For years, the go-to service for authentication and role assignment was XSUAA (Authorization & Trust Management). But SAP’s new strategy is clear: move towards an integrated model using SAP Cloud Identity Services – with Identity Authentication Service (IAS) for authentication and the Authorization Management Service (AMS) for fine-grained, instance-based authorizations.
This change is not just cosmetic. It simplifies user management, centralizes policies, and paves the way for more powerful, context-aware access control across all SAP applications. While BTP applications are currently the biggest audience, Cloud Identity Services are designed as the central security platform for all SAP applications – ensuring one consistent foundation for authentication, authorization, and user provisioning across the entire SAP landscape.
Why the Move Away from XSUAA?
Official SAP guidance confirms that BTP is replacing authorization management done with XSUAA by an integrated solution with AMS. While XSUAA bundled authentication and authorization per subaccount, AMS separates these concerns and provides a centralized system. Key reasons include:
- X.509 Support: XSUAA does not natively support X.509 certificate-based authentication or mutual TLS. IAS, in contrast, allows X.509 to be used broadly across SAP applications, enabling stronger system-to-system and regulated communication scenarios.
- Known Limitations: XSUAA is restricted to subaccounts, relies on static scopes defined in xs-security.json, and lacks support for true instance- or attribute-based authorization. It has no central identity directory, limited federation options, and weak lifecycle integration, which often led to manual role maintenance and compliance issues when combined with the SAP Default IDP.
- Compliance & Security: XSUAA was frequently misused with S-Users and the default SAP IDP in productive landscapes, including the BTP cockpit itself, though explicitly discouraged in SAP BTP’s Security Recommendations. This practice raised ISO and GDPR compliance issues, underlining the need for a centralized and standards-compliant approach with IAS + AMS.
- Centralized Policy Management: No more scattered role definitions across subaccounts.
- Attribute-Based Authorizations: AMS supports instance-level conditions (e.g., user.country = record.country).
- Unified Admin Console: Manage authentication, authorization, and user provisioning in one place (SCI administration console).
- Future-Proofing: New SAP services across the portfolio are natively integrated with IAS and AMS.
SAP recommends that new applications should adopt IAS + AMS from the start. Existing applications on XSUAA remain supported, but the strategic direction is clear.
How Role Assignments Work with AMS
User Provisioning and Attribute Flow
A central prerequisite for AMS is that all relevant users are present in the Identity Directory Service. To achieve this in productive landscapes, most customers rely on the Identity Provisioning Service (IPS) to synchronize users from external sources like Microsoft Active Directory / Entra ID (Azure AD), SAP SuccessFactors, or other corporate IdPs. IAS can be federated with these IdPs for authentication, while IPS ensures that user objects, groups, and attributes are copied into the Identity Directory.
This setup has several advantages:
- Federated Authentication: Users continue to log in with corporate credentials via Entra ID, Okta, Ping, or similar, while IAS handles session management and token issuance.
- Attribute Mapping: IPS maps attributes such as department, cost center, or country from AD/Entra ID into the Identity Directory. These attributes can be referenced in AMS policies for instance-based restrictions (e.g., user.department = record.department).
- Group-to-Policy Mapping: AD/Entra ID groups can be synchronized into IAS and mapped to AMS policies. Thus, corporate group memberships translate directly into role assignments in BTP applications.
- Lifecycle Automation: User changes (e.g., transfers, terminations) flow automatically from the corporate directory to the Identity Directory, ensuring that AMS policy enforcement always reflects the current state. This closes gaps seen in XSUAA setups, where role collections often required manual maintenance in the cockpit.
AMS changes how developers and administrators think about role assignments:
- Identity Directory as Prerequisite: Users must reside in the Identity Directory Service of Cloud Identity. This ensures all role and policy assignments happen centrally and consistently across applications.
- CAP Integration: In CAP projects, CDS role annotations are transformed into AMS Policies. These can include both role names and instance-based filters derived from annotations like @restrict.
- Policy Administration: Generated policies appear in the SCI console as assignable groups. Admins can refine these (for example, by binding attribute values such as country=DE) and assign them to users.
- Runtime Enforcement: IAS issues tokens, CAP (or other runtimes) fetches the assigned AMS policies, and the app enforces them. The integration is transparent to developers thanks to CAP plugins.
The result is more flexible and maintainable authorization management than the old xs-security.json model tied to XSUAA.
Migration Considerations
Many existing BTP applications still rely on XSUAA. SAP has clarified that these applications remain fully supported, so there is no forced migration. However, new services are increasingly delivered with IAS and AMS only. For customers, this means:
- Plan user provisioning into the Identity Directory early, as it is the prerequisite for AMS.
- Expect future SAP solutions to ship without XSUAA integration.
- Use CAP’s tooling (cds add ias, cds add ams) to simplify setup of IAS + AMS in new projects.
Fallback Support for XSUAA Tokens
A practical blocker for AMS adoption in the past was that CAP apps could not consume XSUAA-issued tokens when authenticating via IAS. With the July 2025 CAP release, this has changed. CAP’s IAS authentication strategies can now automatically accept XSUAA-issued tokens as a fallback, provided the necessary bindings exist. By adding xsuaa: true in the project configuration, a CAP app using IAS can handle both IAS and XSUAA tokens seamlessly:
„requires“: {
„auth“: „ias“, // main auth provider
„xsuaa“: true // fallback for XSUAA tokens
}
This removes one of the last technical blockers for adopting AMS in hybrid landscapes, especially when consuming other BTP services that still require XSUAA tokens.
What This Means for You
It is worth noting that IAS + AMS is not limited to CAP applications. While CAP provides out-of-the-box support for IAS/AMS through dedicated plugins and tooling, non-CAP applications can also integrate with IAS and AMS using the official Java and Node.js libraries. This ensures that all custom services on BTP – regardless of framework – can leverage the same centralized authentication and authorization model.
- New CAP Apps: Always use IAS + AMS. Tooling like cds add ias and cds add ams makes this straightforward.
- Existing Apps: You can remain on XSUAA for now, but should plan migration. With fallback support, the risk of disruption is much lower.
- Admins: Ensure all business users are provisioned in the Identity Directory. This central store is key for AMS.
- Developers: Continue using CAP annotations for roles. CAP plugins handle the AMS integration transparently.
Connection to SAP’s Identity Renovation Project
This move also aligns with SAP’s broader Identity Renovation Project, which aims to harmonize and rationalize IAM across all SAP solutions. The initiative emphasizes:
- Customer-owned identities: Shifting from SAP-managed S-Users to customer-managed directories integrated with Cloud Identity.
- Authenticate once: Seamless sessions across SAP applications.
- Customer IAM integration: Enabling customers to use their own IAM solutions while leveraging SAP Cloud Identity Services.
- Simplification: Reducing manual processes tied to legacy S-User concepts and aligning to global standards.
This reinforces the strategy of IAS + AMS as the single, centralized approach for authentication and authorization.
Conclusion
SAP’s vision is clear: a single, centralized identity and authorization platform. With IAS handling authentication and AMS providing powerful, instance-based authorizations, SAP is moving towards simpler, more secure, and more flexible access management across its entire portfolio.
The addition of XSUAA fallback in IAS authentication further accelerates this journey, smoothing out migration challenges. If you are building on BTP today, the direction is unmistakable – go with IAS + AMS. It is time to adopt SAP’s new Identity and Access Management strategy now. With IAS and AMS, you gain a secure, compliant, and future-ready foundation for all SAP applications. Don’t wait until legacy approaches slow you down – reach out today to discuss how we can guide your adoption and accelerate your IAM transformation. If you have any questions, please do not hesitate to contact me.
