From 04403769669f80c1f69ef54d80ac2317c9f03209 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 10:22:51 +0100 Subject: [PATCH 01/10] Example first --- guides/security/authorization.md | 38 ++++++++++++++++---------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/guides/security/authorization.md b/guides/security/authorization.md index 7912c05aaf..ca929bf9dd 100644 --- a/guides/security/authorization.md +++ b/guides/security/authorization.md @@ -413,7 +413,25 @@ The [restrict annotation](#restrict-annotation) for an entity allows you to enfo In addition, you can define a `where`-condition that further limits the set of accessible instances. This condition, which acts like a filter, establishes *instance-based authorization*. -### Filter Conditions { #filter-consitions } +### Filter Conditions + +For instance, a user is allowed to read or edit `Orders` (defined with the `managed` aspect) that they have created: + +```cds +annotate Orders with @(restrict: [ + { grant: ['READ', 'UPDATE', 'DELETE'], where: (CreatedBy = $user) } ]); +``` + +Or a `Vendor` can only edit articles on stock (that means `Articles.stock` positive): + +```cds +annotate Articles with @(restrict: [ + { grant: ['UPDATE'], to: 'Vendor', where: (stock > 0) } ]); +``` + +::: tip +Filter conditions declared as **compiler expressions** ensure validity at compile time and therefore strengthen security. +::: The condition defined in the `where` clause typically associates domain data with static [user claims](cap-users#claims). Basically, it *either filters the result set in queries or accepts only write operations on instances that meet the condition*. @@ -444,24 +462,6 @@ You can define filter conditions in the `where`-clause of restrictions based on -For instance, a user is allowed to read or edit `Orders` (defined with the `managed` aspect) that they have created: - -```cds -annotate Orders with @(restrict: [ - { grant: ['READ', 'UPDATE', 'DELETE'], where: (CreatedBy = $user) } ]); -``` - -Or a `Vendor` can only edit articles on stock (that means `Articles.stock` positive): - -```cds -annotate Articles with @(restrict: [ - { grant: ['UPDATE'], to: 'Vendor', where: (stock > 0) } ]); -``` - -::: tip -Filter conditions declared as **compiler expressions** ensure validity at compile time and therefore strengthen security. -::: - At runtime you'll find filter predicates attached to the appropriate CQN queries matching the instance-based condition. :::warning Modification of Statements From af9c5d842bbc2e60d979beb25444c07f9657151b Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 12:11:43 +0100 Subject: [PATCH 02/10] use standard link target and add link --- guides/security/authentication.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/guides/security/authentication.md b/guides/security/authentication.md index aa0ea414a6..752015c47a 100644 --- a/guides/security/authentication.md +++ b/guides/security/authentication.md @@ -39,7 +39,7 @@ As access control relies on verified claims, authentication is a mandatory prere According to key concept [Pluggable Building Blocks](./overview#key-concept-pluggable), the authentication method can be configured freely. CAP [leverages platform services](overview#key-concept-platform-services) to provide proper authentication strategies to cover all relevant scenarios: -- For _local development_ and _unit testing_, [Mock User Authentication](#mock-user-auth) is an appropriate built-in authentication feature. +- For _local development_ and _unit testing_, [Mock User Authentication](#mock-user-authentication) is an appropriate built-in authentication feature. - For _cloud deployments_, in particular deployments for production, CAP provides integration of several identity services out of the box: - [Identity Authentication Service (IAS)](#ias-auth) provides a full-fledged [OpenId Connect](https://openid.net/connect/) compliant, cross-landscape identity management as first choice for applications. @@ -47,7 +47,7 @@ CAP [leverages platform services](overview#key-concept-platform-services) to pro - CAP applications can run IAS and XSUAA in [hybrid mode](#hybrid-auth) to support a smooth migration from XSUAA to IAS. -## Mock User Authentication { #mock-user-auth } +## Mock User Authentication In non-production profile, by default, CAP creates a security configuration which accepts _mock users_. As this authentication strategy is a built-in feature which does not require any platform service, it is perfect for **unit testing and local development scenarios**. @@ -309,7 +309,7 @@ Integration tests running in production profile should verify that unauthenticat - cross-landscape user propagation (including on-premise) - streamlined SAP and non-SAP system [integration](https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/integrating-service) (due to [OpenId Connect](https://openid.net/connect/) compliance) -IAS authentication is best configured and tested in the Cloud, so let's enhance the started bookshop sample application with a deployment descriptor for SAP BTP, Cloud Foundry Runtime (CF). +IAS authentication is best configured and tested in the Cloud, so let's enhance the [previously started bookshop sample application](#mock-user-authentication) with a deployment descriptor for SAP BTP, Cloud Foundry Runtime (CF). ### Get Ready with IAS { #ias-ready } @@ -324,7 +324,7 @@ towards your IAS tenant to use it as identity provider for applications in your - Ensure your development environment is [prepared for deploying](../deploy/to-cf#prerequisites) on CF, in particular you require a `cf` CLI session targeting a CF space in the test subaccount (test with `cf target`). -You can continue with the sample [already created](#mock-user-auth). In the project root folder, execute +You can continue with the sample [already created](#mock-user-authentication). In the project root folder, execute ```sh cds add mta @@ -706,7 +706,7 @@ XSUAA authentication is best configured and tested in the Cloud, so let's enhanc Before working with XSUAA on CF, you need to ensure your development environment is [prepared for deploying](../deploy/to-cf#prerequisites) to CF. In particular, you require a `cf` CLI session targeting a CF space in the test subaccount (test with `cf target`). -You can continue with the bookshop sample create for the [mock users](#mock-user-auth) or, alternatively, you can also enhance the [IAS-based](#ias-auth) application. +You can continue with the bookshop sample create for the [mock users](#mock-user-authentication) or, alternatively, you can also enhance the [IAS-based](#ias-auth) application. If there is no deployment descriptor yet, execute in the project root folder @@ -1278,7 +1278,7 @@ With `cds.security.authentication.authenticateMetadataEndpoints: false` you can
-Automatic authentication enforcement can be disabled via feature flag cds.requires.auth.restrict_all_services: false, or by using [mocked authentication](#mock-user-auth) explicitly in production. +Automatic authentication enforcement can be disabled via feature flag cds.requires.auth.restrict_all_services: false, or by using [mocked authentication](#mock-user-authentication) explicitly in production.
From b4aa6e8601815ea714b12b05884532504c1431a8 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 12:16:32 +0100 Subject: [PATCH 03/10] todo marker --- guides/security/authentication.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/guides/security/authentication.md b/guides/security/authentication.md index 752015c47a..f6ddc78cff 100644 --- a/guides/security/authentication.md +++ b/guides/security/authentication.md @@ -426,7 +426,11 @@ The startup log should confirm the activated IAS authentication:
+ +```sh TODO +``` +
::: tip @@ -1337,7 +1341,9 @@ In such architectures, CAP authentication is obsolete and can be deactivated ent
+ TODO +
From 83ce6d5d175a381df02a3464a73cea7e760e20e1 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 12:48:30 +0100 Subject: [PATCH 04/10] move repeating information in details block --- guides/security/authentication.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/guides/security/authentication.md b/guides/security/authentication.md index f6ddc78cff..433a70f424 100644 --- a/guides/security/authentication.md +++ b/guides/security/authentication.md @@ -417,6 +417,7 @@ and wait until the application is up and running. You can test the status with `cf apps` on CLI level or in BTP Cockpit, alternatively. The startup log should confirm the activated IAS authentication: +
```sh @@ -710,34 +711,32 @@ XSUAA authentication is best configured and tested in the Cloud, so let's enhanc Before working with XSUAA on CF, you need to ensure your development environment is [prepared for deploying](../deploy/to-cf#prerequisites) to CF. In particular, you require a `cf` CLI session targeting a CF space in the test subaccount (test with `cf target`). -You can continue with the bookshop sample create for the [mock users](#mock-user-authentication) or, alternatively, you can also enhance the [IAS-based](#ias-auth) application. +:::details If you haven't prepared a sample yet... + +You can create a bookshop sample as described in [Mock User Authentication](#mock-user-authentication). -If there is no deployment descriptor yet, execute in the project root folder +Execute the following two commands in the project root folder, only if you haven't prepared your sample for IAS in the previous section already. + +To make your application ready for deployment to CF: ```sh cds add mta ``` -
- -::: tip -Command `add mta` will enhance the project with `cds-starter-cloudfoundry` and therefore all [dependencies required for security](../../java/security#maven-dependencies) are added transitively. -::: - -
- -to make your application ready for deployment to CF. - You also need to configure DB support: ```sh [SAP HANA] cds add hana ``` +::: tip For Java +Command `add mta` will enhance the project with `cds-starter-cloudfoundry` and therefore all [dependencies required for security](../../java/security#maven-dependencies) are added transitively. + +::: ### Adding XSUAA { #adding-xsuaa } -Now the application is ready for enhancing with XSUAA-support: +Enhance your [sample application](#mock-user-authentication) with XSUAA-support:
From f11482fc2a6e653f175d001bce27c083113395dc Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 13:19:44 +0100 Subject: [PATCH 05/10] alice without password --- guides/security/authentication.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/guides/security/authentication.md b/guides/security/authentication.md index 433a70f424..e62ca76bb2 100644 --- a/guides/security/authentication.md +++ b/guides/security/authentication.md @@ -140,9 +140,9 @@ curl http://localhost:4004/odata/v4/admin/Books --verbose results in a `401` error response from the server indicating that the anonymous user has been rejected due to missing authentication. This is true for all endpoints including the web application page at `/index.html`. -Mock users require **basic authentication**, hence sending the same request on behalf of mock user `alice` (password: `basic`) with +Mock users require **basic authentication**, hence sending the same request on behalf of mock user `alice` (no password) with ```sh -curl http://alice:basic@localhost:4004/odata/v4/admin/Books +curl http://alice:@localhost:4004/odata/v4/admin/Books ``` returns successfully (HTTP response `200`). @@ -682,14 +682,15 @@ The same is true for the logout flow. ::: -Now re-deploy the solution by running +Now re-deploy the solution: ```sh cds up ``` -and test the application via URL provided in the Cockpit. -The Application Router should redirect to a login flow where you can enter the credentials of a [test user](#ias-admin) created before. +Test the application using the URL provided in the Cockpit. + +The Application Router should redirect to a login flow where you can enter the credentials of a [test user](#ias-admin) you created before in the Administration Console for IAS. ## XSUAA Authentication { #xsuaa-auth } From 797356744e43e9ca05a430fb629a158ba0e96f4d Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 14:27:45 +0100 Subject: [PATCH 06/10] introduce do don't pattern, better texts for links --- guides/security/overview.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/guides/security/overview.md b/guides/security/overview.md index ce585b638d..2eb397262e 100644 --- a/guides/security/overview.md +++ b/guides/security/overview.md @@ -172,10 +172,13 @@ Security not only plays a crucial role in [cloud environments](#cloud), but also Apparently the security requirements are different from cloud scenario as local endpoints are typically not exposed for remote clients. But there are still a few things to consider because exploited vulnerabilities could be the basis for attacks on productive cloud services: +#### DO:{.good} + - Make sure that locally started HTTP endpoints are bound to `localhost`. -- In case you run your service in hybrid mode with bindings to cloud service instances, -use [cds bind](../../tools/cds-bind) instead of copying bindings manually to `default-env.json` file. -`cds bind` avoids materialization of secrets to local disc, which is inherently dangerous. +- Use [cds bind](../../tools/cds-bind) to run your service in hybrid mode with bindings to cloud service instances. `cds bind` avoids materialization of secrets to local disc, which is inherently dangerous. The opposite is consequently a **Don't**. + +#### DON'T:{.bad} +- Don't copy bindings manually to `default-env.json` file or otherwise on your local disc. - Don't write sensitive data to application logs, also not via debug logging. - Don't test with real business data, for example, copied from a productive system. @@ -234,32 +237,32 @@ The Identity Authentication service defines the user base for (CAP) applications Customers can integrate their third-party or on-premise identity provider (IdP) and harden security by defining multifactor authentication or by narrowing client IP ranges. This service helps to introduce a strict separation between platform users (provider) and business users (subscribers), a requirement of CAP. It supports various authentication methods, including SAML 2.0 and [OpenID Connect](https://openid.net/connect/), and allows for the configuration of single sign-on access. -[Learn more in the security guide.](https://help.sap.com/docs/IDENTITY_AUTHENTICATION?#discover_task-security){.learn-more} +[Learn more in the SAP Cloud Identity - Security Guide.](https://help.sap.com/docs/IDENTITY_AUTHENTICATION?#discover_task-security){.learn-more} #### [SAP Authorization and Trust Management Service](https://help.sap.com/docs/CP_AUTHORIZ_TRUST_MNG) The service allows customers to manage user authorizations in technical roles at the application level, which can be aggregated into business-level role collections for large-scale cloud scenarios. Developers must define application roles carefully as they form the basic access rules for business data. -[Learn more in the security guide.](https://help.sap.com/docs/btp/sap-business-technology-platform/btp-security){.learn-more} +[Learn more in the SAP Authorization and Trust Management service guide.](https://help.sap.com/docs/btp/sap-business-technology-platform/btp-security){.learn-more} #### [SAP BTP Connectivity](https://help.sap.com/docs/CP_CONNECTIVITY) The connectivity service allows SAP BTP applications to securely access remote services that run on the Internet or on-premise. It provides a way to establish a secure communication channel between remote endpoints that are connected via an untrusted network infrastructure. -[Learn more in the security guide.](https://help.sap.com/docs/CP_CONNECTIVITY/cca91383641e40ffbe03bdc78f00f681/cb50b6191615478aa11d2050dada467d.html){.learn-more} +[Learn more in the SAP BTP Connectivity guide.](https://help.sap.com/docs/CP_CONNECTIVITY/cca91383641e40ffbe03bdc78f00f681/cb50b6191615478aa11d2050dada467d.html){.learn-more} #### [SAP Malware Scanning Service](https://help.sap.com/docs/MALWARE_SCANNING) This service scans transferred business documents for malware and viruses. Currently, there is no CAP integration. A scan must be triggered explicitly by the business application. -[Learn more in the security guide.](https://help.sap.com/docs/btp?#operate_task-security){.learn-more} +[Learn more in the SAP Malware Scanning service guide.](https://help.sap.com/docs/btp?#operate_task-security){.learn-more} #### [SAP Credential Store](https://help.sap.com/docs/CREDENTIAL_STORE) Credentials managed by applications must be stored securely. This service provides a REST API for (CAP) applications to store and retrieve credentials at runtime. -[Learn more in the security guide.](https://help.sap.com/docs/CREDENTIAL_STORE?#discover_task-security){.learn-more} +[Learn more in the SAP Credential Store guide.](https://help.sap.com/docs/CREDENTIAL_STORE?#discover_task-security){.learn-more} From abcf040ebb6feb5e2cd028ac140f0f4c904c738f Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 14:41:18 +0100 Subject: [PATCH 07/10] edit pitfalls section --- guides/security/cap-users.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/guides/security/cap-users.md b/guides/security/cap-users.md index 2702725241..a6c06c6ed7 100644 --- a/guides/security/cap-users.md +++ b/guides/security/cap-users.md @@ -1746,22 +1746,23 @@ Prefer using [Remote Services](#remote-services) built on Cloud SDK rather than ## Pitfalls -- **Don't write custom code against concrete user types of a specific identity service (e.g. XSUAA or IAS)**. -Instead, if required at all, use CAP's user abstraction layer (`UserInfo` in Java or `req.user` in Node.js) to handle user-related logic. +- **Don't write custom code against user types of an identity service (XSUAA / IAS)**. + + Instead, if it is required at all to code against user types, use CAP's user abstraction layer (`UserInfo` in Java or `req.user` in Node.js) to handle user-related logic. -- **Don't try to propagate named user context in asynchronous requests**, such as when using the Outbox pattern or Messaging. -Asynchronous tasks are typically executed outside the scope of the original request context, after successful authorization. -Propagating the named user context can lead to inconsistencies or security issues. Instead, use technical users for such scenarios. +- **Don't try to propagate named user context in asynchronous requests**. + + This can happen when using the Outbox pattern or Messaging. Asynchronous tasks are typically executed outside the scope of the original request context, after successful authorization. Propagating the named user context can lead to inconsistencies or security issues. Instead, use technical users for such scenarios. -- **Don't mix CAP Roles for business and technical users**. CAP roles should be clearly separated based on their purpose: Business user roles are designed to reflect how end users interact with the application. -Technical user roles are intended for system-level operations, such as background tasks or service-to-service communication. Mixing these roles can lead to confusion and unintended access control issues. +- **Don't mix CAP Roles for business and technical users**. + + CAP roles should be clearly separated based on their purpose: Business user roles are designed to reflect how end users interact with the application. Technical user roles are intended for system-level operations, such as background tasks or service-to-service communication. Mixing these roles can lead to confusion and unintended access control issues. - **Don't mix AMS Policy level with CAP Role level**. -AMS policies operate at the business level, while CAP roles are defined at the technical domain level. -Avoid mixing these two layers, as this could undermine the clarity and maintainability of your authorization model. + + AMS policies operate at the business level, while CAP roles are defined at the technical domain level. Avoid mixing these two layers, as this could undermine the clarity and maintainability of your authorization model. -- **Don't choose non-cross-sectional entity attributes as AMS Attributes**. -Such attributes should have a broad, domain-wide relevance and be applicable across multiple entities. -Typically, only a limited number of attributes (less than 10) meet this criterion. -Exposing entity-specific attributes as AMS attributes can lead to unnecessary complexity and reduced reusability. +- **Don't choose entity attributes as AMS Attributes whose relevance is too small**. + + Such attributes should have a broad, domain-wide relevance and be applicable across multiple entities. Typically, only a limited number of attributes (less than 10) meet this criterion. Exposing entity-specific attributes as AMS attributes can lead to unnecessary complexity and reduced reusability. From 44a9aa4526f419583b57e937b2c8ca0f7166a6b1 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 15:01:02 +0100 Subject: [PATCH 08/10] add example for unsupported privileges --- guides/security/authorization.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/guides/security/authorization.md b/guides/security/authorization.md index ca929bf9dd..a4416a8ca0 100644 --- a/guides/security/authorization.md +++ b/guides/security/authorization.md @@ -105,12 +105,12 @@ context db { ... } - entity Issues : cuid { // implicitly auto-exposed (by composition) + entity Issues : cuid { // implicitly auto-exposed (by composition in Components) category: Association to Categories; ... } - entity Components : cuid { // explicitly exposed (by projection) + entity Components : cuid { // explicitly exposed (by projection in IssuesService) issues: Composition of many Issues; ... } @@ -267,16 +267,30 @@ Restrictions can be defined on different types of CDS resources, but there are s Unsupported privilege properties are ignored by the runtime. Especially, for bound or unbound actions, the `grant` property is implicitly removed (assuming `grant: '*'` instead). The same also holds for functions: -```cds +::: code-group +```cds [Model w/ unsupported privilege properties] service CatalogService { entity Products as projection on db.Products { ... } actions { @(requires: 'Admin') action addRating (stars: Integer); } - function getViewsCount @(restrict: [{ to: 'Admin' }]) () returns Integer; + function getViewsCount @(restrict: [{ grant: 'READ' to: 'Admin' }]) () returns Integer; } ``` +```cds [Resulting model] +service CatalogService { + entity Products as projection on db.Products { ... } + actions { + @(requires: 'Admin') // is already in implicit {grant: '*'} + action addRating (stars: Integer); + } + //unsupported property is removed, means implicit { grant: '*'} + function getViewsCount @(restrict: [{ to: 'Admin' }]) () returns Integer; +} + +``` +::: ### Combined Restrictions { #combined-restrictions} From 68a83822de53b09199069db4b286433af97a9235 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Fri, 16 Jan 2026 15:19:50 +0100 Subject: [PATCH 09/10] reduce text --- guides/security/authorization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guides/security/authorization.md b/guides/security/authorization.md index a4416a8ca0..46f343f2cc 100644 --- a/guides/security/authorization.md +++ b/guides/security/authorization.md @@ -262,7 +262,7 @@ Restrictions can be defined on different types of CDS resources, but there are s | entity | | | 1 | | | action/function | | | 2 | = `@requires` | -> 1For bound actions and functions that are not bound against a collection, Node.js supports instance-based authorization at the entity level. For example, you can use `where` clauses that *contain references to the model*, such as `where: CreatedBy = $user`. For all bound actions and functions, Node.js supports simple static expressions at the entity level that *don't have any reference to the model*, such as `where: $user.level = 2`. +> 1For bound actions and functions that are not bound against a collection, Node.js supports instance-based authorization at the entity level, see [link] (somewhere in Node.js docs)
> 2 For unbound actions and functions, Node.js supports simple static expressions that *don't have any reference to the model*, such as `where: $user.level = 2`. Unsupported privilege properties are ignored by the runtime. Especially, for bound or unbound actions, the `grant` property is implicitly removed (assuming `grant: '*'` instead). The same also holds for functions: From 766a6cb24017a8db11db4af2c7ddd184e946b4ce Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Mon, 19 Jan 2026 12:36:18 +0100 Subject: [PATCH 10/10] ai review --- guides/security/overview.md | 38 ++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/guides/security/overview.md b/guides/security/overview.md index 2eb397262e..51b3b62443 100644 --- a/guides/security/overview.md +++ b/guides/security/overview.md @@ -36,14 +36,14 @@ For example, authentication can be delegated to a [separate ingress component](. ### Customizable { #key-concept-customizable } -Due to the plugin-based architecture, **CAP allows standard functions to be modified as required or, if necessary, completely replaced**. -This flexibility is crucial for scenarios where the default methods do not fully meet the requirements of the application. +Due to the plugin-based architecture, **you can modify CAP's standard functions as required or, if necessary, completely replace them**. +This flexibility is crucial for scenarios where the default methods do not fully meet your application's requirements. Moreover, this integration helps to easily incorporate non-CAP and even non-BTP services, thereby providing a flexible and interoperable environment. ![Overview Customizable Components with CAP](./assets/security-customizable.drawio.svg){width="600px" } -For instance, it is possible to define specific endpoints with a [custom authentication strategy](./authentication#custom-auth). -Likewise, the CAP representation of the request user can be overruled to match additional, application-specific requirements. +For instance, you can define specific endpoints with a [custom authentication strategy](./authentication#custom-auth). +Likewise, you can override the CAP representation of the request user to match additional, application-specific requirements. ### Built on Best of Breed { #key-concept-platform-services } @@ -59,7 +59,7 @@ Likewise, TLS termination is offered by the [platform infrastructure](#platform- ### Decoupled from Business Logic { #key-concept-decoupled-coding } -As security functions are factorized into independent components, **application code is entirely decoupled** and hence is not subject to change in case of any security-related adaptations. +As security functions are factorized into independent components, **application code is entirely decoupled** and hence is not subject to change for any security-related adaptations. This ensures that business logic remains independent of platform services, which are often subject to security-hardening initiatives. As a welcome side effect, this also allows testing application security in a **local test or development setup in a self-contained way**. @@ -85,7 +85,7 @@ The application is responsible for coordinated overall configuration. ## Security Architecture CAP applications run in a specific context that has a major impact on the security [architecture](#architecture-overview). -CAP requires a dedicated [platform environment](#platform-environment) to integrate with, in order to ensure end-to-end security. +CAP requires a dedicated [platform environment](#platform-environment) to integrate with to ensure end-to-end security. ### Architecture Overview { #architecture-overview } @@ -93,7 +93,7 @@ The following diagram provides a high-level overview of the security-relevant co ![This TAM graphic is explained in the accompanying text.](./assets/cap-security-architecture-overview.png){width="600px"} -To serve a business request, different runtime components are involved: a request, issued by a UI or technical client ([public zone](#public-zone)), is forwarded by a gateway or ingress router to the CAP application. In case of a UI request, an [Application Router](https://help.sap.com/docs/btp/sap-business-technology-platform/application-router) instance acts as a proxy to manage the login flow and the browser session. The CAP application can have additional services such as a CAP sidecar. All application components ([application zone](#application-zone)) might make use of platform services such as database or identity service ([platform zone](#platform-zone)). +To serve a business request, different runtime components are involved: a request, issued by a UI or technical client ([public zone](#public-zone)), is forwarded by a gateway or ingress router to the CAP application. For a UI request, an [Application Router](https://help.sap.com/docs/btp/sap-business-technology-platform/application-router) instance acts as a proxy to manage the login flow and the browser session. The CAP application can have additional services such as a CAP sidecar. All application components ([application zone](#application-zone)) might make use of platform services such as database or identity service ([platform zone](#platform-zone)). #### Public Zone { #public-zone } @@ -107,17 +107,17 @@ Ideally, you should limit the number of exposed endpoints to a minimum, perhaps The platform zone contains all platform components and services that are *configured and maintained* by the application provider. CAP applications consume these low-level [platform services](#btp-services) to handle more complex business requests. -For instance, persistence service to store business data and identity service to authenticate the business user play a fundamental role. +For instance, the persistence service stores business data and the identity service authenticates the business user. Both play a fundamental role. The platform zone also includes the gateway, which is the main entry point for external requests. Additionally, it may contain extra ingress routers. #### Application Zone { #application-zone} -The application zone comprises all microservices that represent a CAP application. They are tightly integrated and form a **unit of trust**. The application provider is responsible to *develop, deploy and operate* these services: +The application zone comprises all microservices that represent a CAP application. They are tightly integrated and form a **unit of trust**. The application provider is responsible for *developing, deploying, and operating* these services: - The [Application Router](https://help.sap.com/docs/btp/sap-business-technology-platform/application-router) acts as an optional reverse proxy wrapping the application service and providing business-independent functionality required for UIs. This includes serving UI content, providing a login flow as well as managing the session with the browser. -It can be deployed as an application (reusable module) or alternatively consumed as a [service](https://help.sap.com/docs/btp/sap-business-technology-platform/managed-application-router). +You can deploy it as an application (reusable module) or alternatively consume it as a [service](https://help.sap.com/docs/btp/sap-business-technology-platform/managed-application-router). - The CAP application service exposes the API to serve business requests. Usually, it makes use of lower-level platform services. As built on CAP, a significant number of security requirements is covered either out of the box or by adding minimal configuration. @@ -144,7 +144,7 @@ This **frees CAP applications from the need to manage trust certificates**. The 3. **Secrets** that are required to protect the application or to consume other platform services **are injected by the platform** into the application microservices in a secure way. -All supported [environments](#cloud) fulfill the given requirements. Additional requirements could be added in future. +All supported [environments](#cloud) fulfill the given requirements. Additional requirements may be added in future. ::: tip Custom domain certificates must be signed by a trusted certificate authority. @@ -190,12 +190,12 @@ Currently, CAP supports to run on two cloud runtimes of [SAP Business Technology - [SAP BTP, Cloud Foundry Runtime](https://help.sap.com/docs/btp/sap-business-technology-platform/cloud-foundry-environment) - [SAP BTP, Kyma Runtime](https://help.sap.com/docs/btp/sap-business-technology-platform/kyma-environment) -Application providers are responsible to ensure a **secure platform environment**. +Application providers are responsible for ensuring a **secure platform environment**. In particular, this includes *configuring* [platform services](#btp-services) the application consumes. -For instance, the provider (user) administrator needs to configure the [identity service](#identity-service) to separate platform users from business users that come from different identity providers. +For instance, you as the provider (user) administrator need to configure the [identity service](#identity-service) to separate platform users from business users that come from different identity providers. Likewise, login policies (for example, multifactor authentication or single-sign-on) must be aligned with company-specific requirements. -Note, that achieving production-ready security requires to meet all relevant aspects of the **development process** as well. +Note that achieving production-ready security requires meeting all relevant aspects of the **development process** as well. For instance, source code repositories must be protected and must not contain any secrets or personal data. Likewise, the **deployment process** must be secured. This includes not only setting up CI/CD pipelines running on technical platform users, but also defining integration tests to ensure properly secured application endpoints. @@ -219,7 +219,7 @@ Find more about BTP platform security here: ### Security Platform Services { #btp-services } -SAP BTP provides a range of platform services that your CAP applications can utilize to meet production-grade security requirements. To ensure the security of your CAP applications, it's crucial to comply with the service level agreement (SLA) of these platform services. *As the provider of the application, you play a key role in meeting these requirements by correctly configuring and using these services.* +SAP BTP provides a range of platform services that your CAP applications can use to meet production-grade security requirements. To ensure the security of your CAP applications, comply with the service level agreement (SLA) of these platform services. *As the provider of the application, you play a key role in meeting these requirements by correctly configuring and using these services.* ::: tip SAP BTP services and the underlying platform infrastructure hold various certifications and attestations, which can be found under the naming of SAP Cloud Platform in the [SAP Trust Center](https://www.sap.com/about/trust-center/certification-compliance/compliance-finder.html?search=SAP%20Business%20Technology%20Platform%20ISO). @@ -227,15 +227,15 @@ SAP BTP services and the underlying platform infrastructure hold various certifi [Webcast SAP BTP Cloud Identity and Security Services](https://assets.dm.ux.sap.com/webinars/sap-user-groups-k4u/pdfs/221117_sap_security_webcast_series_sap_btp_cloud_identity_and_security_services.pdf){.learn-more} -The CAP framework offers flexible APIs that you can integrate with various services, including your custom services. If you replace platform services with your custom ones, it's important to ensure that the service level agreements (SLAs) CAP depends on are still met. +The CAP framework offers flexible APIs that you can integrate with various services, including your custom services. If you replace platform services with your custom ones, ensure that the service level agreements (SLAs) CAP depends on are still met. The most important services for security offered by the platform: #### [SAP Cloud Identity Services - Identity Authentication](https://help.sap.com/docs/IDENTITY_AUTHENTICATION) { #identity-service } -The Identity Authentication service defines the user base for (CAP) applications and services, and allows to control access. -Customers can integrate their third-party or on-premise identity provider (IdP) and harden security by defining multifactor authentication or by narrowing client IP ranges. -This service helps to introduce a strict separation between platform users (provider) and business users (subscribers), a requirement of CAP. It supports various authentication methods, including SAML 2.0 and [OpenID Connect](https://openid.net/connect/), and allows for the configuration of single sign-on access. +The Identity Authentication service defines the user base for (CAP) applications and services, and allows you to control access. +You can integrate your third-party or on-premise identity provider (IdP) and harden security by defining multifactor authentication or by narrowing client IP ranges. +This service helps introduce a strict separation between platform users (provider) and business users (subscribers), a requirement of CAP. It supports various authentication methods, including SAML 2.0 and [OpenID Connect](https://openid.net/connect/), and allows you to configure single sign-on access. [Learn more in the SAP Cloud Identity - Security Guide.](https://help.sap.com/docs/IDENTITY_AUTHENTICATION?#discover_task-security){.learn-more}