Overview of Security Concepts and Architecture
This section provides an overview of the security concepts and architecture of CAP applications on different platforms.
Key Concepts
CAP's security architecture is built on several fundamental principles that enable flexible, secure, and maintainable applications. These concepts work together to provide comprehensive security while maintaining developer productivity and operational efficiency.
Pluggable Building Blocks
CAP divides the different security-related tasks into separate and independent building blocks, each with a standard CAP implementation suitable for most scenarios.
The building blocks are:
By separating these concerns, CAP ensures that each security function can be configured and customized independently without affecting other parts of the system, providing maximum flexibility.
For example, authentication can be delegated to a separate ingress component, while authorization remains within the application service close to the data.
Customizable
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.
For instance, you can define specific endpoints with a custom authentication strategy. Likewise, you can override the CAP representation of the request user to match additional, application-specific requirements.
Built on Best of Breed
CAP does not deal with user login flows, password and credential management, user sessions, or any cryptographic logic - and applications should definitely not do so! Instead, CAP seamlessly integrates with battle-tested platform services that handle these critical security topics centrally. This approach not only simplifies the implementation but also enhances security by leveraging robust, well-tested mechanisms provided by the platform. Built on platform services, CAP allows developers to focus on core application functionality without worrying about the intricacies of security implementation.
Most notably, authentication is covered by CAP-integration of platform's identity services. Likewise, TLS termination is offered by the platform infrastructure.
Decoupled from Business Logic
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.
For instance, CAP allows performing outbound service calls via Remote Services while handling authentication completely under the hood. This abstraction layer ensures that developers do not need to worry about the details of authentication.
Low-level application code is prone to configuration changes
Application code that doesn't build on the abstractions provided by CAP, but instead uses the interfaces of the underlying security services directly, is highly vulnerable to configuration changes or behavioral changes on this level. For example, the application cannot be switched from TLS to mTLS-based communication with the platform services without rewriting custom code, if it doesn't consistently use Remote Services.
Secure by Default
CAP security features are configured by default. If different behavior is required, you must explicitly reconfigure or add custom code accordingly. CAP's security autoconfiguration approach significantly reduces the risk of misconfiguration - override only when absolutely necessary and when all effects are safely controlled.
For instance, endpoints of deployed CAP applications are automatically authenticated, providing a secure baseline. Making endpoints public requires manual configuration in either the CAP model or the middleware.
Application projects are still responsible overall
CAP cannot guarantee end-to-end product security across all application layers by default. 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. CAP requires a dedicated platform environment to integrate with to ensure end-to-end security.
Architecture Overview
The following diagram provides a high-level overview of the security-relevant components and interfaces of a deployed CAP application in a cloud environment:
To serve a business request, different runtime components are involved: a request, issued by a UI or technical client (public zone), is forwarded by a gateway or ingress router to the CAP application. For a UI request, an 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) might make use of platform services such as database or identity service (platform zone).
Public Zone
From CAP's point of view, all components without specific security requirements belong to the public zone. Therefore, you shouldn't rely on the behavior or structure of consumer components like browsers or technical clients for the security of server components. The platform's gateway provides a single point of entry for any incoming call and defines the API visible to the public zone. Since malicious users have free access to the public zone, you must protect these endpoints carefully. Ideally, you should limit the number of exposed endpoints to a minimum, perhaps through proper network configuration.
Platform Zone
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 to handle more complex business requests. 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
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 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. You can deploy it as an application (reusable module) or alternatively consume it as a service.
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.
The optional CAP sidecar (reusable module) is used to outsource application-independent tasks such as providing multitenancy and extension support.
Application providers (platform users) have privileged access to the application zone. In contrast, application subscribers (business users) are restricted to a minimal interface.
Do not share secrets
Application providers must not share any secrets from the application zone such as binding information with other components or persons. In a production environment, we recommend deploying and operating the application on behalf of a technical user.
Platform Requirements
There are several assumptions that a CAP application needs to make about the platform environment it is deployed to:
Application and (platform) service endpoints are exposed externally by the API gateway via TLS protocol. Hence, the CAP application can offer a pure HTTP endpoint without having to enforce TLS and to deal with certificates.
The server certificates presented by the external endpoints are signed by a trusted certificate authority. This frees CAP applications from the need to manage trust certificates. The underlying runtimes (Java or Node.js VMs) can validate the server certificates by default.
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 fulfill the given requirements. Additional requirements may be added in future.
Sign custom certificates
Custom domain certificates must be signed by a trusted certificate authority.
Application endpoints are visible to the public zone
Hence, CAP applications need to protect all exposed endpoints.
Platform Compliance
CAP applications run in a certain environment, that is, in the context of some platform framework that has specific characteristics as explained before. The underlying framework has a major impact on the security of the application, regardless of whether it runs a cloud environment or local environment. Moreover, CAP applications are tightly integrated with platform services, in particular with identity and persistence service.
End-to-end security necessarily requires compliance with all security policies of all involved components
CAP application security requires consistent security configuration of the underlying platform and all consumed services. Consult the relevant security documentation accordingly.
CAP in Local Environment
Security not only plays a crucial role in cloud environments, but also during local development. 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:
- Make sure that locally started HTTP endpoints are bound to
localhost. - Use cds bind to run your service in hybrid mode with bindings to cloud service instances.
cds bindavoids materialization of secrets to local disc, which is inherently dangerous. The opposite is consequently a Don't.
DON'T:
- Don't copy bindings manually to
default-env.jsonfile 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.
CAP in Cloud Environment
Currently, CAP supports to run on two cloud runtimes of SAP Business Technology Platform:
Application providers are responsible for ensuring a secure platform environment. In particular, this includes configuring platform services the application consumes. For instance, you as the provider (user) administrator need to configure the 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 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.
As part of secure operations, application providers must establish patch and vulnerability management, as well as a secure support process. For example, component versions must be updated and credentials must be rotated regularly.
Applications must use secure platform environments
The application provider is responsible to develop, deploy, and operate the application in a secure platform environment. CAP offers seamless integration into platform services and tools to help to meet these requirements.
Find more about BTP platform security here:
SAP BTP SecuritySAP BTP Security RecommendationsSAP BTP Security (Community)
Security Platform 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.
Compliance documents in SAP Trust Center
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.
Webcast SAP BTP Cloud Identity and Security Services
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
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, and allows you to configure single sign-on access.
Learn more in the SAP Cloud Identity - Security Guide.
SAP Authorization and Trust Management Service
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 SAP Authorization and Trust Management service guide.
SAP BTP 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 SAP BTP Connectivity guide.
SAP Malware Scanning Service
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 SAP Malware Scanning service guide.
SAP 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.