Security is one of the most critical components of SAP CAP applications. Whether your app runs locally or on SAP BTP, applying authentication and authorization ensures that users access only the data and actions they are permitted to. CAP provides seamless integration with XSUAA, JWT-based authentication, and powerful role-based access control (RBAC).
This guide breaks down the essentials of CAP security and shows how to implement it correctly.
Why Security Matters in CAP
CAP applications typically expose:
- OData services
- REST endpoints
- Business logic hooks
- Sensitive enterprise data
Without strong authentication and authorization, these endpoints become vulnerable. CAP solves this using:
- XSUAA for authentication
- JWT tokens for identity and tenant awareness
- RBAC for fine-grained authorization
- Scopes & role collections through BTP
Understanding XSUAA Authentication
XSUAA (SAP Authorization & Trust Management) is the key identity provider for CAP applications running on SAP BTP.
It handles:
- User authentication
- Token issuance (JWT)
- Role mappings
- Trust with Identity Providers (IdPs)
- Tenant-specific identity in multitenant scenarios
XSUAA Configuration
You define XSUAA rules in xs-security.json.
Example:
{
"xsappname": "cap-security-app",
"tenant-mode": "shared",
"scopes": [
{ "name": "$XSAPPNAME.Admin", "description": "Admin Access" },
{ "name": "$XSAPPNAME.User", "description": "User Access" }
],
"role-templates": [
{
"name": "Admin",
"scope-references": [ "$XSAPPNAME.Admin" ]
},
{
"name": "User",
"scope-references": [ "$XSAPPNAME.User" ]
}
]
}
JWT Tokens in CAP
XSUAA issues a JWT token after authentication.
The token contains:
- User ID
- Roles & scopes
- Tenant ID (for multitenancy)
- Expiration time
- Issuer
CAP automatically validates JWT tokens and maps claims to req.user.
Example token structure (decoded):
{
"user_name": "hrishi",
"scopes": ["cap-security-app.User"],
"ext_attr": { "zdn": "tenant123" }
}
Accessing JWT claims in CAP
srv.before('*', req => {
console.log(req.user.id);
console.log(req.user.scopes);
});
Implementing Role-Based Access Control (RBAC) in CAP
RBAC ensures users access only authorized operations.
CAP supports RBAC at:
- Entity level
- Service level
- Operation level
- Custom events
1. Protecting Entities in CDS
entity Orders @(restrict: [
{ grant: ['READ'], to: ['User'] },
{ grant: ['WRITE', 'DELETE'], to: ['Admin'] }
]) {
ID : UUID;
amount : Integer;
}
2. Protecting Actions & Functions
action approveOrder @(restrict: [{ grant: ['WRITE'], to: ['Admin'] }]);
3. Protecting entire services
service AdminService @(requires: 'Admin') {
entity Configurations as projection on my.Config;
}
The requires annotation ensures only Admins access the service.
Enforcing Authorization in Handlers
Use CAP’s built-in authorization checks:
this.before('UPDATE', 'Orders', req => {
req.user.requires('Admin');
});
You can also check scopes:
if (!req.user.is('User')) req.reject(403, 'Not authorized');
Creating Roles in SAP BTP
After defining scopes in xs-security.json, you bind them to role collections in SAP BTP Cockpit.
Example role collections:
CAP-Admin→ includes Admin role templateCAP-User→ includes User role template
Assign these collections to users or groups to grant access.
Local Testing With Mock Users
CAP allows local testing without XSUAA using mock strategies.
Enable mock auth:
cds watch --with-mocks
Create a mock user:
{
"user": "admin",
"roles": ["Admin"],
"tenant": "t1"
}
Securing CAP OData Services
OData endpoints can be protected by simply declaring RBAC in CDS.
Example:
service CatalogService @(requires: 'User') {
entity Products as projection on db.Products;
}
CAP will reject unauthorized requests automatically.
Best Practices for CAP Security
- Always use XSUAA in productive environments
- Keep roles separated: Admin vs User vs Auditor
- Never expose internal endpoints without RBAC
- Avoid hardcoding roles in code
- Test with mock users before deployment
- Use HTTPS everywhere
- Validate incoming JWT tokens
- Apply principle of least privilege
Common Security Mistakes to Avoid
- Skipping RBAC in early development
- Mixing admin and business logic roles
- Forgetting scope references in role templates
- Not enabling authentication for custom actions
- Using local JWTs for production
Conclusion
CAP security becomes powerful when you combine:
- XSUAA for authentication
- JWT for identity & tenant resolution
- RBAC for granular authorization
By designing with security in mind, your CAP application becomes reliable, compliant, and ready for enterprise deployment on SAP BTP.
WhatsApp us