Purpose
With the gaining momentum of SAP Fiori adoption for customers using SAP S/4HANA and SAP Business Suites systems, there often seems to be a dialogue when talking about its deployment strategy. Each customer is different and therefore has this unique use cases to deploy SAP Fiori apps. Out of several different customers uses cases, there seems to be one common case where customers seek advice is how to expose SAP Fiori apps to the internet. The detailed insight about this use case is already described by SAP in Considerations and Recommendations for Internet-facing Fiori apps blog.
But in this two series blog, we will talk about technical configuration of Azure services like Application Gateway Web Application Firewall (WAF) and SAML Single Sign-on with Azure AD that can be leveraged to securely configure internet facing SAP Fiori apps deployment on Azure.
To understand different deployment strategy for SAP Fiori, you can refer SAP Fiori Deployment Options and System Landscape Recommendations guide.
Scope Overview
The installation and post configuration of SAP Fiori ABAP System (Embedded or Hub) on Azure is just like on-premises deployment. But for internet facing use cases in Azure, you can leverage some of its cloud native services to build a secure and resilient solution like Azure Application Gateway Web Application Firewall which can act as first line of defense for internet facing use case, and Azure Active Directory (AAD) for SAML based user authentication that enables Single Sign On (SSO) for SAP Fiori.
In these two blogs, we will discuss more about this cloud services and provide technical insight on how it can be configured in Azure. For that, we will consider below customer use case, based on which we will configure Application Gateway and SSO using Azure Active Directory (AAD).
Customer Use Case
In Azure, a customer wants to deploy internet facing SAP Fiori apps and their requirement to access Fiori apps are as below –
- Access SAP Fiori apps from Internet using Public URL, which points to Azure Application Gateway (WAF) Public Frontend IP address.
- SAP Fiori apps should also be accessible from Intranet directly using SAP Web Dispatcher URL.
- For both communication (Internet and Intranet), customer want SSO to be enabled.
The architecture of customer looks like below based on their requirement. This blog does not cover the architecture details like network configuration, high availability etc. for SAP Fiori deployment in Azure.
Application Gateway Overview
Traditionally SAP Web Dispatcher is used by customer for routing and distributing network calls to the correct systems. But there are several functionalities like Web Application Firewall (WAF) which is not available in SAP Web Dispatcher. Refer Can I use a different load balancer instead of SAP Web Dispatcher to understand more about Web Dispatcher.
For an internet facing deployment, SAP recommends of using Web Application Firewall as first line of defense. In Azure, Application Gateway WAF can be used as Web Application Firewall which has built-in firewall to filter any malicious attack from web (HTTP Protocol). An application gateway serves as single point of contacts for users. It distributes incoming application traffic across multiple backend pools, which in our case is Web Dispatcher VM(s). To distribute traffic, an application gateway uses several components described in below figure.
IMPORTANT: Azure Application Gateway also performs routing and distributing of network calls to backend pools but it cannot be used as a replacement of SAP web dispatcher for Fiori deployment, as several configurations that enable functionalities in SAP Fiori like User Assistance, SAP Co-Pilot, URL filters and others, cannot be configured just by using Application Gateway.
Architecture details
- When user enter https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/ui2/flp in browser, before the request is sent to an application gateway, it resolves the domain name of the application gateway by using a Domain Name System (DNS) server. Azure controls the DNS entry because all application gateways are in the azure.com domain.
- The Azure DNS returns the IP address (52.252.28.162) to the client, which is the frontend Public IP address of the application gateway.
- The application gateway accepts incoming traffic based on one or more listener. A listener is a logical entity that checks for connection requests. It is configured with a Frontend IP address (52.252.28.162), protocol (HTTPS), and port number (443) for connections from clients to the application gateway.
- If a web application firewall (WAF) is in use, the application gateway checks the request headers and the body, if present, against WAF rules. This action determines if the request is valid request or a security threat.
If the request is valid, it is routed to the backend. If the request is not valid and WAF is in Prevention mode, it is blocked as a security threat. If it is in Detection mode, the request is evaluated and logged, but still forwarded to the backend server. Refer WAF modes for more details. - If a request is valid and not blocked by WAF, the application gateway evaluates the request routing rule that is associated with the listener. This action determines which backend pool to route the request to.
- When the application gateway selects the backend pool (sleswd1 – 10.0.17), it sends the request to one of the healthy backend servers in the pool. The health of the server is determined by a health probe.
If the backend pool contains multiple servers, the application gateway uses a round-robin algorithm to route the requests between healthy servers. This load balances the requests on the servers. - After the application gateway determines the backend server, it opens a new TCP session with the backend server based on HTTP settings. HTTP settings specify the protocol (HTTPS), port (443), and other routing-related settings that are required to establish a new session with the backend server.
The port and protocol used in HTTP settings determine whether the traffic between the application gateway and backend servers is encrypted or is unencrypted.
NOTE: Application gateway supports TLS termination at the gateway, but for internet facing SAP Fiori apps it is not advisable to use TLS termination.
Application Gateway Configuration
For Application Gateway, there are two SKUs that are available – v1 SKUs and v2 SKUs. Each of this SKUs has two tiers - Standard and Web Application Firewall (WAF). So, Azure offers four different tiers for application gateway.
- Standard
- Standard v2
- WAF
- WAF v2
The v2 SKU offers performance enhancements and adds support for critical new features like autoscaling, zone redundancy, and support for static VIPs. Refer Feature comparison between v1 SKU and v2 SKU, which compares feature available with each SKU. Existing features under the Standard and WAF SKU continue to be supported in the new v2 SKU, with a few exceptions listed in Differences from v1 SKU.
For internet facing SAP Fiori apps, you can either use WAF or WAF v2 application gateway tier. But there are some differences in the setup process for end-to-end TLS with respect to the version of Application Gateway SKU being used. You can refer End-to-end TLS with the v1 SKU and End-to-end TLS with the v2 SKU for more details on the same.
Also, each WAF SKUs has different support for Frontend IP address type (Public, Private or Both). Below table describes current support of Frontend IP address type for each WAF SKUs. For up to date information, always refer FAQs about Application Gateway article.
| Application Gateway | Public | Private | Both |
| WAF SKU v1 | SKU: Basic IP Assignment: Dynamic | IP Assignment: Static or Dynamic | Supported |
| WAF SKU v2 | SKU: Standard IP Assignment: Static | Not Supported | Supported Private IP Assignment: Static |
In this blog, we will configure customer use case using WAF v2 tier which is also a preferred option due to its performance enhancement and new features.
Pre-requisites for SAP Systems
To configure end-to-end TLS, you make sure to configure TLS/SSL on each layer i.e. ABAP System, Web Dispatcher before you can proceed with Application Gateway configuration.
NOTE: In this article, we will be configuring fourth connection type, where the request is terminated at SAP Web Dispatcher. Both the incoming connection and the outgoing connection use HTTPS. Therefore, you have to configure SAP Web Dispatcher as an SSL server and SSL client.
Source: SAP
After completing both the steps, make sure you can access SAP Fiori using HTTPS URL of Web Dispatcher.
Assumptions
- For SSL configuration, we used Private CA for signing all the servers and client certificates i.e., Application Gateway (.pfx), Web Dispatcher and Application Server. Generally for internet facing use case, application gateway certificate must be signed by trusted CA authority.
- Fiori application with SSL setup (https) is already deployed prior to this setup.
Configure Application Gateway WAF v2
Before you begin
To configure end-to-end TLS/SSL encryption with Azure Application Gateway WAF v2, you need certificate for the gateway. Certificates are also required for the back-end servers. For end-to-end TLS encryption, the right backend servers must be allowed in the application gateway. To allow this access, upload trusted root certificates (for v2 SKU) of the back-end servers to the application gateway. Adding the certificate ensures that the application gateway communicates only with known back-end instances. This configuration further secures end-to-end communication. For more details about certificates, refer End-to-end TLS with the v2 SKU
For Azure to communicate between the resources you create, it needs a virtual network. In this illustration, we will be deploying Application Gateway on the same virtual network as that of Web Dispatcher. But application gateway instances are created in separate subnets. So, you need to create separate subnet for application gateway.
IMPORTANT: A single subnet cannot support both v1 and v2 application gateway SKUs. For more details about subnet, its sizing or configuration options, refer FAQ about Application Gateway.
Application Gateway Infrastructure Configuration
An application gateway is dedicated deployment in your virtual network. Within your virtual network, a dedicated subnet is required for application gateway.
Create separate subnet in virtual network. Refer size of the subnet for more details on the subnet sizing.
Network Security Groups
You want to provide limited access to application gateway from internet and for that you can attached Network security groups (NSGs) to application gateway subnet. But there are some restrictions:
- You must allow incoming Internet traffic on TCP ports 65503-65534 for the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2 SKU with the destination subnet as Any and source as GatewayManager service tag. This port range is required for Azure infrastructure communication. These ports are protected (locked down) by Azure certificates. External entities, including the customers of those gateways, can't communicate on these endpoints.
- Outbound Internet connectivity cannot be blocked. Default outbound rules in the NSG allow Internet connectivity. We recommend that you:
- Do not remove the default outbound rules.
- Do not create other outbound rules that deny any outbound connectivity. - Traffic from the AzureLoadBalancer tag with the destination subnet as Any must be allowed.
Sample example of network security group
NOTE: I have opened 443 port, which is used by listener in application gateway to listen to incoming request.
Attached NSG to the subnet
Create Public IP
Login to Azure Portal > Create a Resource > Search “Public IP address”
For application gateway WAF v2, Public IP address SKU should be Standard as mentioned in above Application Gateway Configuration section.
For DNS hostname resolution, the FQDN s4hanatesting.eastus2.cloudapp.azure.com resolves to the public IP of the resource in azure.com domain. This public IP will be associated to the application gateway which is described in next section. If you want custom domain, you can use Azure DNS or external DNS for your DNS record.
Generate Certificate
To configure end-to-end TLS communication, a TLS/SSL certificate is required to be added to the listener to enable the Application Gateway to derive a symmetric key as per TLS/SSL protocol specification. The symmetric key is then used to encrypt and decrypt the traffic sent to the gateway. The TLS/SSL certificate needs to be in Personal Information Exchange (PFX) format. This file format allows you to export the private key that is required by the application gateway to perform the encryption and decryption of traffic.
To generate the CSR, you can use IIS or other third-party utility. Once the CSR is generated, you can get it signed from trusted CA authority. For reference, you can follow this article Using Microsoft IIS to generate CSR and Private Key to generate CSR.
Create Application Gateway
Login to Azure Portal > Create a Resource > Networking > Application Gateway
NOTE: If you already have a dedicated subnet for application gateway, you can use the same subnet, but a single subnet cannot support both v1 and v2 SKU. So, if you have a dedicated subnet for application gateway v1 SKU, you cannot use the same subnet for v2 SKU and vice versa. You will need a separate gateway subnet for each SKU (v1 and v2).
Application Gateway WAF can be configured to run in detection and prevention mode. For more details on each mode, refer WAF modes. It is recommended that you run a newly deployed WAF in Detection mode for a short period of time in a production environment. This provides the opportunity to obtain firewall logs and update any exceptions or custom rules prior to transition to Prevention mode. This can help reduce the occurrence of unexpected, blocked traffic.
For “Public IP address”, select the public IP address created in earlier section.
Click on “Add a backend pool”
sleswd1.internal.cloudapp.net is FQDN of SAP Web Dispatcher
NOTE: When you create a virtual network, Azure automatically sets up name resolution, so the VMs in it can communicate with each other using host names instead of IP addresses. Although this is very convenient, it has many limitations. For example, it does not work across peered VNets. That is VMs in one VNet can't resolve the host names of VMs in a peered VNet. So, in case if you are running application gateway in one VNet and Web Dispatcher in another VNet and you have established VNet-Peering, then your application gateway won't be able to resolve the host names of Web Dispatcher. You could solve this by setting up a custom DNS server or by using Azure DNS. For more details, see Name resolution for resources in Azure virtual networks
Click on “Add a routing rule”
Protocol (HTTPS): It is a protocol which will be used by user.
Port (443): It a port on which application gateway will listen user request.
PFX certificate file: Upload the signed certificate file you have received from CA authority
Cert name: Provide some name to the certificate
Password: Type the password
Click on “Backend targets”
Click on “HTTP settings” > “Add new”
NOTE: HTTP Settings contain all the information about your backend server.
For v2 SKU, you need trusted root certificate of backend server. In this example, our backend server is web dispatcher (sleswd1), so we will export the root certificate of web dispatcher in (.cer) format.
The root certificate for web dispatcher is internal.cloudapp.net which needs to be downloaded in .cer format and upload in HTTP in application gateway. The root certificate is a base64 encoded root certificate from the backend server certificates.
In addition to the root certificate match, Application Gateway v2 also validates if the host setting specified in the backend HTTP Setting matches that of the common name (CN) presented by the backend server’s TLS/SSL certificate. When trying to establish a TLS connection to the backend, Application Gateway v2 sets the Server Name Indication (SNI) extension to the Host specified in the backend http setting.
As we have maintained FQDN in BackendPool-WD-VMs, we will select Pick host name from backend target in Host name override.
NOTE: If you have maintained IP address in Backend Pool, then you have to select Override with specific domain name option and mention the FQDN of your Web Dispatcher.
Click on “Add”
Validation will be successfully passed if there are no issues with the certificates.
NOTE: Deployment of application gateway takes around 15-25 mins. So, grab a cup of coffee.
After provisioning of application gateway, you will get below error in overview page. (DON’T PANIC)
All the instances in one or more of your backend pools are unhealthy. This will result in a 502 error when you try to access your application hosted behind the Application Gateway. Please check the backend health and resolve the issue.
Before investigating further on this, we need to make a change in the health probe first.
Click on the health probe
Make following changes -
Path: /sap/public/ping (Make sure you have activated ping service in SICF tcode)
Use Probe matching conditions: Yes
NOTE: In “Host” field, maintain the same hostname as the one you had maintained in “host name override” field in HTTP settings.
Click on “Test”. You might get below error, but you can ignore the error and “Save”
The Common Name (CN) of the backend server certificate does not match the host header entered in the health probe configuration (v2 SKU) or the FQDN in the backend pool (v1 SKU). Verify if the hostname matches with the CN of the backend server certificate.
Once the changes are saved, navigate to “Backend Health” section in your application gateway. The status of backend health should be healthy.
Once your backend health status is healthy, the 502 error which we had seen earlier will no longer exist.
NOTE: There are many reasons on getting 502 bad gateway error. For more details, you can check Troubleshoot Bad Gateway errors - Azure Application Gateway article.
Web Dispatcher Parameters
In web dispatcher, below parameters needs to be set.
wdisp/system_<x> = SID=<Fiori_SID>, MSHOST=<Fiori_Msg_Server_Host>, MSPORT=<Msg_Server_HTTP_Port>, SRCSRV=*:443, SRCURL=/sap/opu;/sap/public;/sap/bc;/sap/es;/sap/saml2
wdisp/ssl_encrypt = 1
wdisp/ping_protocol = https
wdisp/group_info_protocol = https
wdisp/url_map_protocol = https
wdisp/server_info_protocol = https
wdisp/add_client_protocol_header = true
wdisp/handle_webdisp_ap_header = 1
wdisp/add_xforwardedfor_header = true
icm/server_port_<x> = PROT=HTTPS,PORT=443,TIMEOUT=900,PROCTIMEOUT=900,EXTBIND=1
exe/icmbnd = $(DIR_CT_RUN)/icmbnd
NOTE: Keep the timeout of Web Dispatcher ICM port same as the timeout of application gateway.
Application Gateway Verification
Once the application gateway is configured, access SAP Fiori launchpad.
https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/ui2/flp
NOTE: The certificate is not signed by trusted CA authority. But in my desktop, I have internal.cloudapp.net root certificate as trusted root certificate.
In next blog, we will go in details on how to configure SSO for both communication method (Internet and Intranet).
Regards,
Dennis Padia
- SAP Managed Tags:
6 Comments
