BTP & Integrationintermediate

BTP CAP Part 3: Securing CAP Services with XSUAA Role-Based Authorization

Key takeaway

Secure CAP declaratively: @requires and @restrict annotations for roles and instance-based conditions, generating xs-security. json with cds compile, mocked users for local testing, XSUAA in production, and testing authorization in hybrid mode.

Explanation

📌 KEY POINTS
✅ @requires restricts a service or entity to roles (e.g. 'authenticated-user', 'Admin').
✅ @restrict defines grants per event (READ, WRITE, actions) and instance conditions (where).
✅ Locally, mocked users in package.json simulate roles; in production, XSUAA tokens provide them.
✅ cds add xsuaa / cds compile generate xs-security.json from annotations.
⚠️ Services without any @requires are open to all authenticated (or even anonymous) users depending on setup.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 built services. Now security.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 1. @REQUIRES\n• Service/entity-level roles.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 2. @RESTRICT\n• Grants, events, where-conditions.

━━━━━━━━━━━━━━━━━━━━
▶ 3. LOCAL MOCKS

Mocked users and roles.

━━━━━━━━━━━━━━━━━━━━
▶ 4. XSUAA

Generated xs-security.json; role collections.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TESTING

Local, hybrid, deployed.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Add @requires: 'authenticated-user' to CatalogService.
Add @restrict for AdminService.
Test with mocked users; then deploy with XSUAA.

✅ CHECKPOINT: non-admins get 403 on AdminService.

Code example

ABAP Code

===== srv/services.cds =====service AdminService @(requires: 'Admin') { entity Books as projection on my.Books; }annotate CatalogService.Books with @(restrict: [  { grant: 'READ', to: 'Viewer' },  { grant: ['READ','WRITE'], to: 'Editor', where: 'country = $user.country' } ]); ===== package.json (mocked users) ====="cds": { "requires": { "auth": { "kind": "mocked", "users": {  "alice": { "roles": ["Admin"] }, "bob": { "roles": ["Viewer"], "attr": { "country": "DE" } } } } } } ===== XSUAA =====cds add xsuaa   # generates xs-security.json from annotations

Real project scenario

A team secured endpoints in handler code with if-statements; one handler missed a check and exposed data. Moving to @requires/@restrict annotations made authorization consistent and generated XSUAA roles.

Common mistakes

Security in handlers.
Missing @requires.
Attributes not configured.
No mocked user tests.
Manual xs-security edits drifting.

Best practices

Declarative annotations.
Default-deny mindset.
Configure attributes.
Test with mocked users.
Generate xs-security.json.

Interview angle

Questions: "@requires vs @restrict?", "How do you test authorization locally?", "How do CAP roles reach XSUAA?"
Strong answer: annotations, instance conditions, mocks, XSUAA generation, testing.

Practice this lesson

Quick check

1. Authorization checks were written in handler if-statements and one was missed. What is the recommended approach?

2. When a CAP service is served without any explicit protocol configuration, which OData protocol version is exposed by default?

3. Which CDS annotation is used at the service level to restrict access so that only users assigned a specific business role can consume the service?

Interview questions

1. Secure a CAP app so viewers read only their country's data and admins manage everything.

Answer it in your own words first, then compare.

2. A production issue is reported in CAP. What would you check first, and how would you troubleshoot it systematically?