Elevate User Experience and Security of Application Load Balancer for SAP workloads on AWS

Introduction

Thousands of customers run SAP workloads on AWS, and customers are looking to accelerate their business process transformation by building cloud-native application extensions on AWS. Customers are leveraging 200+ AWS services to maintain a clean core for their ERP system, streamline upgrades, and innovate at pace with evolving business needs using AWS-native capabilities.
Security is top priority at AWS. A key focus for customers in this modernization journey is strengthening their security posture by enforcing least privilege and propagating identities across complex system boundaries. One use-case is when users are accessing SAP resources from cloud-native application extensions hosted on AWS.
A critical enabler for a better user experience is principal propagation—the ability to carry a verified identity from the initial point of authentication, such as the Application Load Balancer (ALB) from AWS, to backend systems like SAP without requiring re-authentication. This ensures SAP resources trust the identity validated by ALB and enforce least privileged access through user authorizations.
This blog post focuses on how Application Load Balancer (ALB), X.509 certificates, and Mutual Transport Layer Security (mTLS) enable a Single Sign-On (SSO) experience for SAP users accessing SAP resources in mission critical SAP ERP systems from AWS hosted cloud-native extensions.

What is Principal Propagation ?

Principal propagation lets users sign in once to access multiple systems securely, eliminating the need to log in multiple times. It ensures that once a user is authenticated e.g., via a client certificate at the ALB, that identity is consistently recognized and trusted by downstream systems like SAP. This avoids the need for redundant login prompts and maintains a secure user context across the landscape. It enables single sign-on (SSO) by allowing the identity of a user to be forwarded to a system, ensuring actions are performed under the user’s identity, not a system user’s, and improving security by relying on token-based authentication.

Key Benefits of Principal Propagation

• Better User Experience with Single Sign On (SSO): Users need to authenticate only once to access multiple systems and applications, eliminating the frustration of repeated login prompts and maintaining productivity across different platforms.
• Security Enhancement: By eliminating the need for storing multiple credentials and reducing authentication touchpoints, principal propagation strengthens the security posture. It creates a unified security context that maintains clear audit trails and enforces consistent security policies across integrated systems, making it harder for potential attackers to compromise the environment.
• Compliance and Governance: Organizations can maintain better compliance with regulatory requirements through comprehensive user activity tracking and accountability. Principal propagation ensures that user actions are properly attributed and logged across all systems, simplifying audit processes and regulatory reporting.
• Administrative Efficiency: IT teams can manage user access, permissions, and credentials from a single point of control, simplifying user lifecycle management and streamlining routine administrative tasks.
• System Integration: Principal propagation serves as a bridge between different systems and platforms, maintaining consistent user context and authorization across system boundaries. This integration is particularly valuable in modern hybrid environments where applications span multiple platforms and cloud services.
• Cost Reduction: Organizations benefit from reduced help desk tickets, simplified security implementations, and more efficient resource utilization through centralized management.

How can mTLS Authentication support Principal Propagation ?

Mutual Transport Layer Security (mTLS) Authentication establishes a secure, two-way encrypted connection between client and server. Unlike standard TLS, where only the server provides a certificate, mTLS requires both parties to present digital certificates. With this mechanism, users will experience seamless authentication with better security posture between client and servers.

Figure 1. mTLS authentication flow between client and server

In mTLS authentication scenario, you will need to provision the client and server certificate using your Certificate Authority (CA), to ensure both are trusted. The authentication process works as follows:

1. The client requests a connection to the server.
2. The server presents its certificate.
3. The client verifies the server’s certificate.
4. The client presents its certificate for server verification and authentication.
5. Secure connection established between client and server.

mTLS Client Authentication with Application Load Balancer

ALB supports mTLS authentication. It offers two modes: passthrough and verify mode.
In order to ensure secure data flow, all SSL (Secure Socket Layer) or TLS certificates used across the infrastructure, including those at the ALB, SAP Web Dispatcher, and S/4HANA systems should originate from a single and trusted root certificate authority to ease the implementation and maintenance of these certificates.

mTLS Passthrough Mode

In mTLS passthrough mode, ALB forwards the client’s entire certificate chain to backend targets. This is done via an HTTP header named X-Amzn-Mtls-Clientcert. The chain, including the leaf certificate, is sent in URL-encoded PEM format with +, =, and / as safe characters. Below are the consideration while using mTLS Passthrough Mode.

• ALB adds no headers if client certificates are absent; backends must handle this.
• Backend targets are responsible for client authentication and error handling.
• For HTTPS listeners, ALB terminates client-ALB TLS and initiates new ALB-backend TLS using target-installed certificates.
• ALB’s TLS termination allows use of any ALB routing algorithm for load balancing.

mTLS Verify Mode

To enable mTLS verify mode, create a trust store containing a CA certificate bundle. This can be accomplished using AWS Certificate Manager (ACM), AWS Private CA, or by importing your own certificates. Manage revoked certificates using Certificate Revocation Lists (CRLs) stored in Amazon S3 and linked to the trust store.
ALB handles client certificate verification against the trust store, effectively blocking unauthorized requests. This approach offloads mTLS processing from backend targets, improving overall system efficiency. ALB imports CRLs from S3 and performs checks without repeated S3 fetches, minimizing latency.
Beyond client authentication, ALB transmits client certificate metadata through HTTP Headers (e.g., X-Amzn-Mtls-Clientcert-Leaf) to the backend SAP Web Dispatcher via HTTP headers. This allows for additional logic implementation on backend targets based on certificate details, to meet the requirement for SAP Servers to preserve original “Host Header” information.
This enables the server to process client certificate metadata consistently, even when originating from non-SAP sources like an AWS load balancer terminating the SSL connection. In the event that you are implementing end-to-end encryption through ALB – SAP Web Dispatcher – SAP Servers, you must configure SAP Web Dispatcher profile parameters such as icm/HTTPS/client_certificate_header_name. For more details you can refer to this link.

Recommendation

We recommend to implement mTLS verify mode for SAP workload deployment on AWS, because it allows you to offload verification and authentication as early as possible (at ALB layer).The mTLS verify mode is also supported for RISE with SAP on AWS.

Architecture Pattern for mTLS verify mode

Figure 2. mTLS verify authentication data flow for SAP workload on AWS

The architecture above describes how mTLS authentication is implemented in the enclosed on-premise and AWS VPC through AWS Direct Connect. The mTLS authentication can also be implemented for remote user with internet connectivity.

Architecture Flow

1. Users will have X.509 certificate installed in their client devices (laptop and/or mobile).
2. Client device will initiate connection to ALB and shares the respective certificate so both can verify each-other. ALB verification will leverage Amazon S3 as trust store.
3. Once verified, ALB will forward the connectivity to SAP Web Dispatcher for verification and authentication.
4. SAP Web Dispatcher will then forward the connectivity to SAP Instances (i.e. S/4HANA, ABAP Stacks, etc.) for verification and authentication.

Implementation Steps

You can find the detailed implementation steps here. These configuration steps establish the foundation for secure client-server authentication:

1. Configure your trust store using Amazon S3.
   • Create an Amazon S3 bucket to store your private Certificate Authority (CA) and intermediate certificates.
   • Configure your trust store through the EC2 console, linking it to your S3 bucket.
   • Implement Certificate Revocation Lists (CRLs) for additional security control over network connections.
2. Configure your Application Load Balancer (ALB).
   • Request the SSL Public Certificate for ALB using AWS Certificate Manager.
   • Create HTTPS Listener to enable mTLS by associating it to the requested SSL Public Certificate.
   • Create a dedicated Security Group for the SAP Web Dispatcher by configuring inbound rules to permit traffic exclusively from the ALB.
   • Create a Target Group for SAP Web Dispatcher and mapping it to the ALB.
3. Configure SAP Web Dispatcher to target SAP Instances (i.e SAP S/4HANA) as the backend.
   • Import the Root and Intermediate Certificate into the SAP WebDispatcher using sapgenpse command.
   • Generate SSL Public Certificate (from the same private CA) for SAP Web Dispatcher, then install it using sapgenpse command.
   • CImplement SAP Parameter icm/HTTPS/client_certificate_header_name = x-amzn-mtls-clientcert, you can refer to the SAP documentation.
4. Configure SAP S/4HANA to accept the secure connectivity.
   • Import the Root and Intermediate Certificate into the STRUST Transaction in the SAP S/4HANA.
   • Implement SAP Parameter icm/trusted_reverse_proxy with the detail of the SSL Certificate assigned to SAP Web Dispatcher, you can refer to the SAP documentation.

Pricing

More detailed information on Application Load Balancer pricing is available at this link. Specifically to mTLS authentication, there is an additional per-hour per-trust store associated to the ALB based on mTLS Verify use-case scenario. We can assume your S/4 HANA application receives an average of one new connection per second, each lasting two minutes. A client sends an average of five requests per second and the total processed bytes for requests and responses is 300 KB per second. You have configured 1 rules on the load balancer to route your client requests, and 1 trust store associated for Mutual TLS scenario. We calculate your monthly Application Load Balancer costs using pricing in the US East (Northern Virginia) Region as follows:

• New connections (per second): Each LCU provides 25 new connections per second (averaged over the hour). Since your application receives one new connection per second, this translates to 0.04 LCUs (one connection per second / 25 connections per second).
• Active connections (per minute): Each LCU provides 3,000 active connections per minute. Your application receives one new connection per second, each lasting two minutes. This translates to 120 active connections per minute, or 0.04 LCUs (120 active connections per minute / 3,000 active connections per minute).
• Processed Bytes (GBs per hour): Each LCU provides 1 GB of processed bytes per hour. Since each client connection transfers 300 KB of data per second, it translates to 1.08 GB per hour or 1.08 LCUs (1.08 GB/1 GB).
• Rule Evaluations (per second): Because of 10 free rules, this dimension will not affect your pricing.
• Using these values, the hourly bill is calculated by taking the maximum LCUs consumed across the four dimensions. In this example, the processed bytes dimension (1.08 LCUs) is greater than new connections (0.04 LCUs), active connections (0.04 LCUs), and rule evaluations (0 LCU) resulting in a total charge of $0.00864 per hour (1.08 LCUs * $0.008 per LCU) or $6.22 per month ($0.00864 * 24 hours * 30 days).
• Adding the hourly charge of $0.0225 (ALB hour) and the hour charge of 0.0056 (trust store), the total Application Load Balancer costs are:
• $0.03674 per hour ($0.0281 hourly charge + $0.00864 LCU charge); or
• $26.4528 per month ($0.03114 * 24 hours * 30 days).

Conclusion

Application Load Balancer’s mTLS support provides a robust foundation for implementing principal propagation in SAP landscapes. This integration enables secure, scalable, and maintainable SSO solutions while leveraging AWS’s managed services.
Key takeaways:

• ALB’s mTLS support simplifies principal propagation implementation.
• Integration with SAP Web Dispatcher ensures proper mapping of credentials.
• AWS managed service reduces operational overhead.
• Enhanced security through certificate-based authentication.

By implementing mTLS authentication using ALB, organizations can improve their SAP application security posture while providing a better user experience for their employees. This solution is particularly relevant for enterprises running SAP workloads on AWS who need to maintain secure and efficient authentication mechanisms across their application landscape. Remember to always follow AWS Well Architected Framework (SAP Lens) which contains best practices for security and keep your certificates and trust stores updated regularly.

Read more on AWS for SAP blogs to get inspiration on how you can get more out of your SAP investment.

Join the SAP on AWS Discussion

In addition to your customer account team and AWS Support channels, we have recently launched re:Post – A Reimagined Q&A Experience for the AWS Community. Our AWS for SAP Solution Architecture team regularly monitor the AWS for SAP topic for discussion and questions that could be answered to assist our customers and partners. If your question is not support-related, consider joining the discussion over at re:Post and adding to the community knowledge base.

Credits

I would like to thank the following team members for their contributions: Derek Ewell, Sreenath Middhi, Rajendra Narikimelli, Joachim Aumman, Arne Knoeller, and Adam Hill.