From XSUAA To AMS: Architecting S4HANA CAP Extensi...

Introduction

In modern SAP landscapes, extending S/4HANA is no longer just about building services or exposing APIs. The real complexity lies in how to secure enterprise extensions in a scalable and maintainable way.

Traditionally, SAP applications on SAP BTP have relied on XSUAA (XSUAA OAuth service) for authentication and authorization. While this model works well for scope-based access control, enterprise requirements often go beyond simple roles. They often involve business-context-based restrictions such as country, company code, or organizational unit.

As many of us, I have extensively used XSUAA to secure enterprise applications in SAP landscapes. In one of my recent projects, I had the opportunity to work with the IAS + AMS-based authentication and authorization model. That is when the WHY behind this architecture shift became clear.

As always, I wanted to share my learnings through a practical example – starting with the core concepts, followed by architectural differences and then a hands-on implementation.

The GOAL was not just to build another CAP application, but to understand a key architectural shift.

Let's get started by understanding the core design differences between the two authorization strategies

Core Architecture Differences

In SAP BTP –

XSUAA has traditionally been the standard service for securing applications using scopes, role templates and role collections.
With AMS, the security model shifts toward a clearer separation between identity and authorization.

Let's start by understanding each model and key ideas behind it.

XSUAA Mental Model

Following diagram shows how the XSUAA model works in a simple way

Figure-1

Key Ideas

IAS is the Identity Provider (IdP) responsible for authenticating users and establishing their identity.
XSUAA is the OAuth Authorization Server for the application, which issues JWT tokens containing scopes.
Authorization is scope-driven, where access control is enforced using scopes, role templates and role collections embedded inside the JWT token consumed by the application.

AMS Mental Model

Following diagram shows how the AMS model works in a simple way

Figure-2

Key Ideas

IAS is the Identity Provider (IdP) responsible for authenticating users and establishing identity.
AMS is the policy-based Authorization Engine that evaluates access rules based on roles, attributes and business conditions.
Authorization is policy-driven, where access is determined using configurable policies (e.g., country, company code) instead of static scopes.

Responsibility Shift

This comparison highlights a fundamental shift in how authorization is modeled: From static scopes defined at design time to dynamic policies evaluated at runtime.

Aspect	XSUAA	AMS
Configuration file	xs-security.json	*.dcl
Authorization building blocks	Roles + Scopes	Roles + Policies + Attributes
Instance based data restrictions	Leads to role explosion	Stable roles + Dynamic policies
Change impact	Redeploy needed	Policy update
Runtime evaluation	JWT scopes	Policy-driven (via ams plugin)

To make this architecture concrete, let’s walk through a simple vendor onboarding application that demonstrates how IAS, AMS and CAP work together in practice.

End-To-End Implementation: Hands-On

I have built a side-by-side extension – Vendor Onboarding application where:

Requesters can create and view vendor onboarding requests
Reviewers can approve or reject requests with comments
Role-based visibility is enforced using AMS policies to restrict data access

The following solution diagram illustrates the main components of the application

Btp_Solution_Diagram.drawio.png

Figure-3

The above solution diagram illustrates the end-to-end architecture of the Vendor Onboarding application, including the CAP service, App Router, IAS authentication, AMS-based authorization and the SAP HANA persistence layer. It provides a high-level view of how the components interact in the overall system.

The complete GitHub repository for this implementation is publicly available and contains detailed documentation covering all aspects of the solution. In following sections, we will walk through some of the key AMS-related concepts and configurations used in this implementation.

AMS Authorization Policies

The cds add ams command generates an ams/dcl/ folder at the project root:

ams/dcl/
  schema.dcl                - AMS attribute schema (auto-generated; user-editable)
  cap/
    basePolicies.dcl        - auto-generated by cds build — DO NOT edit
  vendor/onboarding/
    reviewerPolicies.dcl    - hand-written app-based policies

Adding @restrict at the entity level is what triggers CAP's AMS plugin to generate basePolicies.dcl

@restrict: [
  { grant: ['READ', 'CREATE'], to: 'VendorRequester', where: 'requestedBy = $user' },
  { grant: ['READ', 'UPDATE', 'DELETE'], to: 'VendorReviewer' }
]

cds build translates this into

POLICY "VendorRequester" {
  ASSIGN ROLE "VendorRequester";
}

POLICY "VendorReviewer" {
  ASSIGN ROLE "VendorReviewer";
}

Instance Based Policies

To restrict VendorReviewers to specific countries, instance-based authorization is achieved by combining AMS schema attributes with policy definitions.

Defining AMS schema attributes: The first step is to expose relevant business fields as AMS attributes using CDS annotations. In this case, the country field is marked as an authorization attribute as shown below

@AMS.attributes: { country: (country) }
entity VendorRequests as projection on db.VendorRequests { ... }

cds build then generates schema.dcl with: This registers country as a condition attribute usable in AMS policies.

SCHEMA {
  country: String
}

Write instance policies in ams/dcl/vendor/onboarding/reviewerPolicies.dcl:

POLICY "VendorReviewer_US" {
  ASSIGN ROLE "VendorReviewer" WHERE country = 'US';
}

POLICY "VendorReviewer_CA" {
  ASSIGN ROLE "VendorReviewer" WHERE country = 'CA';
}

This model enables fine-grained, instance-based authorization where the same CAP role (VendorReviewer) behaves differently depending on the policy context (e.g., country).

Instead of creating multiple roles per country, AMS allows authorization rules to be externalized into policies, improving scalability and maintainability.

The repository README contains the complete implementation details and configuration steps for this setup.

Wrap-Up

In this blog, we explored a practical implementation of a SAP CAP-based Vendor Onboarding extension secured using IAS and AMS and compared it with the traditional XSUAA-based security model.

The key objective was not just to build an application, but to understand the architectural shift in how enterprise authorization is modeled on SAP BTP.

With XSUAA, authorization is primarily scope-driven, where roles, role templates and role collections define access boundaries. While this model works well for standard role-based access control, it becomes rigid when enterprise requirements demand contextual restrictions such as country, organization, or cost center.

Disclaimer: This is not an official reference application or documentation. The thoughts outlined in this blog are based on my real world experience and learnings.

Feel free to “like“, “Share“, “Add a Comment” and to get more updates about my next blogs follow me!

References

Source link