Enforcing authorization in CAP

The fleet app is built with CAP, which enforces authorization declaratively: annotations in the model say who may do what, and CAP checks them on every request before custom handlers run. That puts the security rules where reviewers and testers can read them, next to the services they protect, instead of scattered through code.

Authentication strategies

CAP chooses an authentication strategy per profile. In development, the default is mocked authentication: basic authentication with predefined mock users such as alice (with the admin role) and bob, plus any users you configure under cds.requires.auth.users with roles and attributes. CAP's documentation warns that mocked authentication is not suitable for production. In production, jwt or xsuaa uses tokens issued by SAP Authorization and Trust Management, and ias uses SAP Cloud Identity Services. An anonymous request to a protected service gets 401.

@requires and @restrict

@requires names the roles (or pseudo-roles) needed to use a service, entity or action at all. @restrict lists privileges, each with grant (events such as READ, CREATE, UPDATE, DELETE, WRITE, action names or *), to (roles) and an optional where condition. CAP's documentation spells out how they combine: within one privilege all properties must be met; between privileges on the same resource at least one must pass; and across levels (service, entity, action) all must pass. Pseudo-roles include authenticated-user, any (the default for to, including anonymous users) and system-user for technical callers.

The fleet app's rules, in srv/fleet-auth.cds:
annotate FleetService with @(requires: ['FleetAgent', 'FleetSupervisor']);
annotate FleetService.Inquiries with @(restrict: [
{ grant: ['READ', 'CREATE', 'UPDATE'], to: 'FleetAgent' },
{ grant: '*', to: 'FleetSupervisor' } ]);
annotate FleetService.closeInquiry with @(requires: 'FleetSupervisor');
annotate CustomerService.Inquiries with @(restrict: [
{ grant: 'READ', to: 'FleetCustomer', where: 'customer = $user.customer' } ]);

Instance-based authorization

The where clause makes rules depend on the data. $user.customer refers to the user's customer attribute, which CAP treats as a list: the condition passes if any value matches, and an empty or missing attribute denies access. On READ, the condition filters results, so a Great Lakes Fleet Services contact sees only their own inquiries. CAP's documentation notes a detail testers must know: when a READ of a single entity fails the check, CAP answers 404 Not Found rather than 403, so as not to disclose that the record exists; failed UPDATE and DELETE on single entities answer 403.

From CDS roles to xs-security.json

cds add xsuaa adds the XSUAA service to the project and generates xs-security.json from the model: for every role in the CDS model, one scope and one role template with exactly that name, and one attribute for every user attribute used in conditions. cds compile srv --to xsuaa regenerates it after model changes. CAP's documentation warns that if you edit the file by hand, scope names must still exactly match the role names in CDS, because those names are checked at runtime; CAP strips the $XSAPPNAME prefix when it maps scopes to roles.