Application Load Balancer for SAP Enterprise Portal

Introduction

For SAP Java applications such as SAP Enterprise Portal (EP), customers use SAP Web dispatcher as an entry point of their HTTP(s) requests. SAP Web dispatcher receives the requests  coming from internet or intranet and distributes the requests among the application servers. For internet-based HTTP(s) requests, SAP Web dispatcher needs to be accessible to the internet which requires it to be installed in a public subnet. Many SAP customers avoid having EC2 instances on public subnet to reduce possible attack surface thus reducing potential blast radius.

This blog describes how customers can use Elastic Load Balancing (ELB) for SAP EP applications. SAP EP applications use Application Load Balancer (ALB) to load balance HTTP requests. Unlike SAP Web dispatcher, ALB is serverless service and fully managed by AWS. You can configure an ALB to be Internet facing which serves HTTP(s) traffic to the SAP EP. With ALB, customers are able to integrate with AWS Web Application Firewall (WAF) to address known vulnerabilities, Amazon CloudFront for content acceleration, and AWS Certificate Manager (ACM) to manage TLS/SSL certificates.

Application Load Balancer and its features

ALB is a highly available service which takes HTTP(s) requests from clients and distributes them to the target groups based on rules. Each target group contains the IP addresses or EC2 instance-ids and HTTP(s) port combination of single or multiple application server for the SAP EP. HTTP(s) requests will be forwarded by ALB to application servers.

ALB can meet the following SAP EP requirements

1. Layer 7 HTTP(s) Load balancing service, that is highly available, and able to distribute requests across multiple Availability Zones (AZs).
2. Highly secure, reliable and scalable managed AWS service which does not require any manual server maintenance (serverless).
3. HTTP(s) requests can be forwarded to multiple application servers based on host and/or port-based mapping.
4. TLS/SSL encryption offloading. ALB works with SSL certificates to encrypt traffic between the load balancer and the client. Incoming traffic must pass strict checks against access control lists (ACLs) before reaching the EC2 instances which hosted SAP applications.
5. Support Single Sign On (SSO) support with Simple and Protected GSS-API Negotiation (SPNEGO) and Security Assertion Markup Language (SAML) authentication with Identity Providers such as Active Directory.
6. HTTP Request filtering. WAF can be used along with ALB as an additional security layer against Open Web Application Security Project (OWASP) attacks such as SQL injection mentioned in this blog. It also provides traffic inspection and filter rules support in the form of ACLs and rules. We can define custom rules in WAF as per documentation.
7. SSL certificate management. ACM can be used to manage SSL/TLS certificates as described in this document.

Architecture

1) Single ALB Architecture for SAP EP

We can use a single ALB for distributing load among multiple SAP application servers. ALB can be internet-facing or intranet-facing (also known as internal ALB). For HTTP(s) requests arriving from the customer network either via Direct Connect or Virtual Private Network (VPN), the “internal” ALB forward the requests and load balance to the application servers. However, if customers wish allow users access from internet to SAP EP, it would require an internet facing ALB as shown in figure 1 right side diagram, where internet facing ALB is deployed in a public subnet.

Figure 1: Left – single internal ALB architecture for SAP EP and Right – single internet ALB architecture for SAP EP

2) ALB sandwich architecture for SAP EP

Figure 2: ALB sandwich architecture for SAP EP

We can go for a combination of two ALBs with an internet facing ALB in the Public subnet and a second internal ALB in the private subnet as shown in figure 2, such deployments are capable of reducing blast radius since the SAP application subnet will not be exposed to the internet, and aligned with AWS Well-Architected Framework for resilience while making the architecture more secure.

Architecture Description

• We have considered a two account strategy where the public subnet lies in a network account and a private subnet on AWS production account. You can also deploy the same architecture in a single account.
• The Network account has access to internet while AWS production account has no direct access to internet. This makes AWS production account more secure.
• We have considered two ALBs. ALB in Network Account is an internet facing ALB for SAP EP. This will serve the internet (external) users, and it is connected to the intranet facing (internal) ALB, where it will serve the intranet (internal) users.
• In the figure 2, we have used a distributed set of VM series firewall over multiple AZs and Amazon EC2 Auto Scaling group to improve availability and resiliency.
• Such sandwich architecture is used to address requirements for inbound traffic firewall inspection. Traffic first passes through ALB that is used as a frontend for an Auto Scaling Group of VM Series firewalls. The destination for each firewall is ALB that contains target group behind it (EC2 instances in this case). This approach allows both the security inspection tier, as well as the web front-end tier, to scale in and out independently of each other in a cost-effective manner. More details can be found in this blog.

Internet facing ALB configuration

• Internet facing ALB is configured to listen HTTP or HTTPS traffic. Route HTTP port 80 to HTTPS port 443 to improve security.
• The default security policy ELBSecurityPolicy-2016-08 is the recommended policy for both internet facing and internal load balancers because it supports TLSv1.2.
• For HTTPS listener, we deploy one SSL/TLS server certificate on ALB using ACM certificates or third-party certificates.

The flow is as follows:

1. Traffic is received at internet facing ALB.
2. It forwards the traffic to the firewall instances-based target group.
3. At firewall instance, a static Network Address Translation (NAT) or port-to-host NAT policy is used to route traffic to internal  ALB.
4. Internal ALB will receive the traffic from the firewall.

Internal ALB configuration

• Port 80 defined as an HTTP port for listening incoming requests from internet facing ALB routed via Firewall.
• Port 443 defined as HTTPS port which listens for users directly accessing SAP EP within the corporate network.
• The default security policy ELBSecurityPolicy-2016-08 is the recommended policy for both internet facing and internal load balancers because it supports TLSv1.2
• For HTTPS listener, we deploy one SSL/TLS server certificate on ALB using ACM certificates or third-party certificates.

Figure 3: Internal ALB Listeners

Target groups of internal ALB

All the IP addresses of SAP EP application servers are added to a target group. Please note although EC2 instances can be added, it is preferable to add “IP addresses” as the targets, because EC2 instance ids can change in case of termination due to failures and new instances can take its place.

Figure 4: Target group for SAP EP of internal ALB

SAP EP Target Group attributes

Figure 5: Stickiness attributes for SAP EP

SAP EP requires application-based stickiness to be enabled. It is required to pass subsequent requests to the relevant application server to support stateful user session. We need to make sure that backend SAP EP is adding that saplb_* cookie, and ALB will copy its value and create another cookie called AWSALBAPP-* cookie.  The stickiness duration must be adequate enough to ensure that a user’s session is always routed by ALB to a particular application server. It can be adjusted based on requirements. We recommend to go for working hours or a day.

Listener rules

A listener is a process that checks for connection requests. using the protocol and port that you configure. You define a listener when you create ALB, and you can add listeners to your load balancer at any time. For example, as shown in figure 3, we defined two listeners in internal ALB:

1. HTTP 80 for traffic arriving from internet facing ALB
2. HTTPS 443 for traffic arriving from corporate network

The listener rules for a listener determine how ALB routes requests to its registered targets. Each rule consists of a priority, one or more actions, and one or more conditions. Please refer to this documentation for more details.

Internal ALB listener rules

The table below describe example rules and configuration at ALB.

The above two listener rules 5 and 6 will ensure that User Management Engine (UME) admin can only be accessed internally by system administrator.

Rule 5 denotes that UME Admin is allowed to be accessed from ip address within internal corporate subnet range 10.0.0.0/8 or 192.168.138.0/24 or 192.168.139.0/24

Rule 6 denotes that UME Admin is not allowed to be accessed from other ip addresses.

Figure 6: Internal ALB HTTPs listener port 443 configuration

Internet-facing ALB listener rules

When the HTTP(s)  requests reach the internet facing ALB, which listens at port 443, it forwards the traffic to internal ALB which is defined as a target group of the internet facing ALB.

As per the listener rule, when there is a request to UME Admin from internet, it will be blocked as per figure 7 and figure 8.

Figure 7: Internal ALB HTTP Listener Port 80 configuration

Figure 8: Result while trying to access User Admin URL from internet

ALB attributes and Security considerations

• It is recommended for ALB to drop invalid packets and ensure ALB is configured for HTTP headers with header fields that are not valid are removed by the load balancer.
• TLS 1.2 is in effect on the ALB level as it has enhanced security when compared to TLS 1.1
• Delete protection must be disabled incase EC2 Auto Scaling is planned.
• Idle timeout should be equal or more to the processing timeout of the SAP application. By default, SAP EP has a timeout of 600 seconds which has to be incorporated in both internet and intranet facing ALB.

ALB support for accessing SAP ECC backend content through SAP EP over the internet

We would like to ensure that ALB supports connectivity to SAP EP as well as redirect to SAP ECC backend from SAP EP over the internet. For more information about how the traffic flows from SAP EP to SAP ECC backend over the open network, please visit this SAP blog.

Some customers have strict policies which allow only a single Fully Qualified Domain Name(FQDN) and port combination for internet traffic. In such cases, distributing load among multiple SAP systems can only be achieved by context or path-based mapping. For example: if customers allow only a single external ALB with port 443 and it needs to allow connection to SAP EP and SAP Fiori, the listener rule condition must have mapping by path “/irj/portal” or “/nwa” for SAP EP and “/fiori” for SAP Fiori. This might create conflict of paths when we only have one ALB, especially those common contents such as “/icon”, “/sap”, and so on. It is therefore advisable to have a combination of two or more ALB for multiple SAP solutions to be architected for internet facing and intranet users.

The following architecture shows two pairs of ALBs used with context-based mapping, one for SAP EP and other pair for SAP ECC to reach respective applications.

Figure 9: Multi ALB architecture for SAP ECC content access from SAP EP over internet

We have considered two pairs of ALBs to achieve this goal of having SAP ECC functionality via SAP EP over the internet. Pair 1 contains an internet-facing and Internal ALB with the architecture as explained previously for SAP EP. Pair 2 contains another set of an internet facing and an internal ALB for SAP ECC system.

We have to ensure that the SAP ECC webdynpro URLs are directly not accessible over the internet but accessible via only SAP EP or systems of the same domain.

This is achieved by implementing a listener rule in the SAP ECC internet facing ALB for SAP ECC as shown in figure 10, in which the “HTTP Header Referer” field ensures that the ECC services can be accessed only from ess-ep.example.com ALB FQDN and direct access of any ECC service over the internet is blocked with HTTP response 402 for example.

Figure 10: HTTP Header Referer in ECC ALB Listener Rule

The internal ALB for SAP ERP can be directly accessed over listener port 443 so it can be directly accessed from the internal corporate network or can be referred from SAP EP.

Figure 11: ESS iView in SAP EP

Figure 12: System alias configuration

Internet users, for instance, can login to SAP EP ALB-based Portal URL https://ess-ep.example.com/irj/portal and access an Employee Self Service (ESS) webdynpro application running on SAP ECC, which is set up with SAP ECC ALB at https://ess-ecc.example.com/sap/bc/webdynpro/ZHRESS as described in figure 11.

A “system alias” for SAP ECC has been defined with SAP ECC ALB FQDN to enable direct SSO from SAP EP as shown in figure 12 through https://<EP-ALB URL >/irj/portal -> System Administration -> System Landscape. The Internet Transaction Server (ITS) hostname and application server hostname for SAP ECC has been defined with SAP ECC ALB FQDN.

Expected HTTP request flows:

• Users will first access the URL for the SAP EP Portal, which opens the /irj/portal
• The request will reach internet facing SAP EP ALB before flowing through VM series firewall
• It is then forwarded to internal ALB for SAP EP and finally SAP EP application servers.
• Once inside SAP EP, user clicks on ESS tab, the request will be redirected to internet facing ALB for SAP ECC.
• Then the request is sent to VM series firewall, and reaches SAP ECC internal ALB which verifies the listener rule(s).
• Based on matching condition, it sends the traffic to SAP ECC Target group to reach SAP ECC application servers.

If users attempt to visit the SAP ECC webdynpro URLs directly via the internet, access will be refused because the SAP EP ALB, which is the “Referer” as indicated in the rule, is the only way to access the ECC ALB as described in figure 10.

Since the HTTP Referer has only been implemented on the external ALB side, intranet users connecting directly to the internal ALB will not experience any issues accessing the URLs directly or indirectly.

ALB Performance Analysis and Troubleshooting

In order to monitor ALB performance, you can go to Amazon CloudWatch console, metrics and select the desired ALB or navigate to EC2 console -> Load Balancing -> Target Groups, select the desired target group and clock on Monitoring tab. More information can be obtained on the following AWS documentation. Below is an example graphics of CloudWatch metrics for ALB that shows an average “Target Response Time” of approximately 150-200 ms for request count of 1500-2000 requests in a duration of half an hour during peak Indian business hours.

Figure 13: Amazon Cloudwatch ALB performance metrics

You can refer to this knowledge base to troubleshoot ALB performance for high latency or timeout issue. Once narrow down the issue related to SAP EP, please check icm logs or default traces for clues. Please check SAP Note 2579836 to resolve such issues.

Conclusion

In this blog post, we dove deep on the use case as well as architectural patterns and the setup procedure of ALB for SAP EP application. Customers are using ALB for their SAP applications in order to leverage many of its functionalities and advantages. ALB is an AWS managed service which needs no maintenance of the underlying operating layer or EC2 instance. It comes as a highly available and scalable service which simplifies your SAP landscape.

You can find out more about SAP on AWS from the AWS product documentation.

If you require additional expert guidance, contact your AWS account team to engage a local SAP specialist solution architect or the AWS Professional Services SAP specialty practice.

Join the SAP on AWS Discussion

In addition to your customer account team and AWS Support channels, you can engage with us at re:Post – A Reimagined Q&A Experience for the AWS Community. Our SAP on AWS Solution Architecture team regularly monitor the SAP on AWS 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.

This blog was co-authored by Sumit Dey.