Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
dennispadia
Active Contributor

Purpose


First Segment: SAP on Azure: Application Gateway Web Application Firewall (WAF) v2 Setup for Internet facing SAP Fi...

In the first segment of this blog series, we had discussed in detail about Application Gateway overview and technical steps to configure Application Gateway WAF v2 for internet facing SAP Fiori apps. Now in this blog we will be extending the use case further, where we will configure Single Sign-On (SSO) using SAML and Azure Active Directory (AAD) for both Public and Internal communication method.

SSO using SAML & Azure Active Directory: Overview


In first part of the blog, we discussed technical configuration of Application Gateway WAF for internet facing SAP Fiori apps. Now the customer wants to offload the user authentication on to an identity provider for both internal and public URLs. The identity provider enables you to federate identities across domains for single sign-on (SSO).

Public URL: https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/ui2/flp

Internal URL: https://sleswd1.internal.cloudapp.net/sap/bc/ui2/flp

In this example, we will configure SSO with the use of SAML by enabling SAP AS ABAP system as service provider and configuring Azure Active Directory as an identify provider.  But before that it is crucial to understand the architecture and flow of request before we perform the configuration.


Before you proceed reading following section, it will be beneficial if you read Using Proxies wiki from SAP. Also check the first part of this blog SAP on Azure: Application Gateway Web Application Firewall (WAF) v2 Setup for Internet facing SAP Fi... that describes SAP Web Dispatcher parameters.

Pre-requisites on SSO Configuration for Public URL



  1. When user enters https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/ui2/flp in web browser, the request is sent to application gateway with HTTP host header s4hanatesting.eastus2.cloudapp.azure.com. Based on the rule defined in HTTP settings, request will be sent to the backend host.

  2. As mentioned in previous blog, to use an HTTP setting with a trusted root certificate you must override incoming HTTP host header (reference link). In our example, we have selected Pick host name from backend target. So, application gateway will decrypt the request and encrypt it again by overriding the HTTP host header from s4hanatesting.eastus2.cloudapp.azure.com to sleswd1.internal.cloudapp.net


  3. Now the request is passed to Web Dispatcher in backend pool with host header as sleswd1.internal.clouapp.net. To identify which HTTP host header Web Dispatcher receives from Application Gateway, we will perform proxy testing using below URL.
    https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/bsp/sap/system_test/test_proxy.htm
    NOTE: You might need to activate SYSTEM_TEST service in SICF on ABAP System.
    As you can see, the host from URL is s4hanatesting.eastus2.cloudapp.azure.com but the host header is sleswd1.internal.cloudapp.net.
    If we forward the request with HTTP host header sleswd1.internal.cloudapp.net for SSO user authentication in Azure Active Directory, the reply Assertion Consumer Service (ACS) URL maintained in AAD will not match with host URL and will result into error.
    NOTE: The issue arises only when your Application Gateway URL is different than your Web Dispatcher URL. But in case if your Application Gateway URL is same as Web Dispatcher, Test#1 status in proxy testing will be successful.

  4. To address above concern, follow below points:
    - If your Application Gateway URL is different than your Web Dispatcher URL, then you must make sure that you preserve the host header s4hanatesting.eastus2.cloudapp.azure.com in Web Dispatcher when the request is sent through application gateway.
    - To preserve the host header in web dispatcher, we need to manipulate header fields in application gateway.
    - To activate the modification of HTTP requests, you first need to set icm/HTTP/mod_<xx> parameter. In this example, below parameter is maintained in Web Dispatcher profile running on Linux.
    icm/HTTP/mod_0 = PREFIX=/, FILE=$(DIR_PROFILE)/redirect.txt
    redirect.txt is the file where we will be defining the expression to handle header fields.

    NOTE:
    If you want to enable this parameter in Web Dispatcher running on windows, set the file path in the parameter accordingly- Create redirect.txt and insert below lines. Restart web dispatcher.
    # Preserver Application Gateway Host header
    if %{HEADER:X-ORIGINAL-HOST} = s4hanatesting.eastus2.cloudapp.azure.com
    begin
    SetHeader HOST s4hanatesting.eastus2.cloudapp.azure.com
    end


    When incoming X-ORIGINAL-HOST is s4hanatesting.eastus2.cloudapp.azure.com, it will set the host header as s4hanatesting.eastus2.cloudapp.azure.com

  5. After performing above step, perform proxy test again
    https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/bsp/sap/system_test/test_proxy.htm
    As you can now see, Application Gateway HTTP host header is preserved in Web Dispatcher.


  6. So now the question arises, whether to maintain HTTPURLLOC in AS ABAP system or not? The HTTPURLLOC table must be configured if no Web Dispatcher Access Points are used, or in all cases if the start URL must be generated from the AS ABAP system.
    In our example, Web Dispatcher Access points are being used because we maintained wdisp/handle_webdisp_ap_header = 1 parameter in Web Dispatcher (as mentioned in earlier blog).
    Now for ABAP system to start BSP application like transaction code SAML2, SOAMANAGER etc., there is no incoming HTTP request available, and thus, no information is available about the proxy. If such a scenario is to be supported, then the relevant info must be configured in HTTPURLLOC
    NOTE: The sort sequence is of importance when a start URL is to be generated. In this case, the first entry in sort sequence is used to generate the URL. So, if the start URLs are always to be generated to be via the proxy, place these entries first. For example, in our case when we enter SOAMANAGER transaction in ABAP system, it will always open application using s4hanatesting host and port.
    Run the proxy test again. We can now see all reverse proxy configuration test got passed.




Configuring AS ABAP as a Service Provider


This section provides an overview of the steps to take to configure SAP Netweaver Application Server (AS) ABAP as a Security Assertion Markup Language (SAML) 2.0 service provider. As a service provider, the AS ABAP enables you to off-load the authentication of users onto an identity provider. The identity provider enables you to federate identities across domains for single sign-on (SSO). Once logged on, SAML 2.0 enables single logout (SLO).

Activating HTTP Security Session Management on SAP NetWeaver AS for ABAP


To configure SAP Fiori as service provider, you need to configure HTTP security sessions management for the client on which you need to configure SAML. With an existing security session, users can then start applications that require a user logon without logging on again. When a security session is ended, the system also ends all applications that are linked to this security session. In this example, we are configuring HTTP security sessions management for QAS client 100.

Login to QASCLNT100. Start HTTP Session Management (transaction SICF_SESSIONS).


Select the relevant line and choose Activate.


NOTE: Adjust the parameters based on your organization requirements. The above parameters are given only as an example.

For more information on each of this parameters, see Activating HTTP Security Session Management on AS ABAP.

Enable SAML 2.0 Support


Start the SAML 2.0 configuration application (transaction SAML2)


If you have never configured your system for SAML 2.0, the system will display above message. Choose the Enable SAML 2.0 Support pushbutton.


Enter a name for the provider.


Continue through the configuration wizard and enter data as desired.

This procedure only covers enabling SAML 2.0. Once enabled, you can configure the bindings supported by the service provider, trust an identity provider, configure identity federation, and protect resources with SAML. The configuration creates two Secure Store and Forward (SSF) applications and associates Personal Security Environment (PSE) files with them. The PSE files contain the signing and encryption key pairs of the service provider.



Change Selection Mode to Automatic


Activate below services in SICF transaction

/default_host/sap/public/bc/sec/saml2

/default_host/sap/public/bc/sec/cdc_ext_service


To download the metadata, make sure SAML 2.0 configuration UI is accessed directly via application gateway URL.

https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/webdynpro/sap/saml2?sap-client=100

Accessing the SAML 2.0 configuration UI using application gateway will ensure that service provider metadata contains the correct endpoint URLs (URLs which are accessible by Identity Provider). For more information, see SAP Note 2326063 - SAML2: How to configure when using proxy/web dispatcher


On clicking “Download Metadata” if you are getting 503 Service Not Available error message, refer to SAP Note 2767055. It happens when you are trying to download metadata by using SAP Web Dispatcher/Proxy host.

Open metadata.xml, you will see that all service endpoint contains application gateway URL.



Configuring Azure Active Directory as an Identity Provider


Register Enterprise Application in Azure AD


Sign in to the Azure portal using your credential.

Select Azure Active Directory services.

Navigate to Enterprise applications


Click on New application. Search for SAP Fiori


Click on SAP Fiori application and enter the name QAS100.


Click on Create.


Click on Set up single sign on


Select SAML single sign on method


Click on Upload metadata file


metadata.xml file will populate all the fields in Basic SAML Configuration beside Sign on URL. So fill up that field with respective Sign on URL.


Click save


Identity federation provides the means to share identity information between partners (SAP System and Azure AD). To share information about a user, partners must be able to identify the user, even though they may use different identifiers for the same user. The SAML 2.0 standard defines the name identifier (name ID) as the means to establish a common identifier. Once the name ID has been established, the user is said to have a federated identity.

The service provider (ABAP System) receives the SAML subject identifier with the specified assertion subject name ID or assertion attributes from the identity provider (assertion attributes can be used as a user ID source only for UnspecifiedTransient, and Email formats). The setting of the User ID Source field defines where this SAML subject identifier is obtained. The service provider (ABAP System) uses the assertion subject name ID or another assertion attribute to get the user identifier. The service provider then checks the User ID Mapping Mode to determine how to find the user in the ABAP system. When the service provider finds the local user, it authenticates the user.

In this illustration, we will configure user authentication using email ID that is maintained in SU01 of the user.

The SAP Fiori application expects the SAML assertions to be in a specific format. Configure the following claims for this application. To manage these attribute values, in the Set up Single Sign-On with SAML pane, select Edit.


Click on Unique User Identifier (Name ID)




Delete user.mail, user.givenname and user.surname in additional claims.


Copy the claim name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name in notepad, it will be used when we specify the identity federation in service provider (ABAP System)


In SAML Signing Certificate, you need to add certificate. Click on Add a certificate


Enter the relevant email address on which you want to receive all notification.


Click save


Download Certificate (Base64) and Federation Metadata XML



Assign Azure AD user


In this section, we will enable testuser to use Azure single sign-on by granting access to SAP Fiori.

Click on Users and Groups in QAS100 enterprise application


Click on Add user


Select the Users and click on Assign



Trusting an Identity Provider


After configuring identify provider in Azure, we will use this procedure to identify an identity provider for your service provider to trust. The service provider requests identity information from the identity provider, which you configure the service provider to trust, for applications the service provider is protecting.

Start the SAML 2.0 configuration application (transaction SAML2).


Click on Add pushbutton and select Upload Metadata File


Browse the Federation Metadata XML file which you have downloaded in above section.


Upload Certificate (Base64) certificate you have downloaded in above section


Click Next


Make sure that the value in the Digest Algorithm box is SHA-256


Under Single Sign-On Endpoints, select HTTP POST



Click Finish



In Trusted Provider > Identity Federation. Select Edit.


Click Add


Select Unspecified


In Details of NameID Format “Unspecified”

User ID Source: Assertion Attribute

User ID Mapping Mode: Email

Assertion Attribute Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

Assertion Attribute Name is the namespace we copied in our earlier section while configuring User & Attribute for our QAS100 enterprise application in AAD.


Click on save and Enable to enable the identity provider.




Create user in SU01


In SU01, maintain the user email id same as that of the user in Azure AD



Test the application


Public URL: https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/ui2/flp




SSO Configuration for Internal URL


In the architecture diagram shown in the earlier part of the blog, customer wants to access SAP Fiori launchpad using internal URL when they are inside their corporate network. The internal URL directly access SAP Web Dispatcher that dispatches traffic to SAP Fiori. So, in this section we will be extending our setup to configure SSO for Internal URL as well.

Internal URL – https://sleswd1.internal.cloudapp.net/sap/bc/ui2/flp

All the steps mentioned in the earlier section of the blog needs to be performed before you proceed further.

Adjust Single Sign-On Setup with SAML in Azure AD


To configure SSO for internal URL, we will need to update few things to make it work.

Login to Azure Portal > Azure Active Directory > Enterprise Applications > QAS100


Click on Single Sign On


Select Edit in Basic SAML Configuration. Maintain below URL in Reply URL (Assertion Consumer Service URL)

https://sleswd1.internal.cloudapp.net/sap/saml2/sp/acs/100


Click on Save

Adjust Authentication Requirement in SAML2 transaction


After adding internal URL in Azure active directory enterprise application (QAS100), we need to make some changes in AS ABAP system.

Start the SAML 2.0 configuration application (transaction SAML2).

Navigate to Trusted Providers > Authentication Requirements and click Edit


Change Assertion Consumer Service to ACS URL and Binding to HTTP Post and click Save.

Check IMPORTANT NOTE section below if you cannot ACS URL in drop down list



Test the application


Internal URL: https://sleswd1.internal.cloudapp.net/sap/bc/ui2/flp




Important Note


This entire configuration is performed on SAP Fiori Front End Server 2020 release and if you are performing this configuration in other Netweaver version, you might not see ACS URL in Assertion Consumer Service. Instead, you will only find two option, Default and Application URL in Assertion Consumer Service. In that case, you need to select Application URL in Assertion Consumer Service and HTTP Post in Binding.

Along side changing Assertion Consumer Service to Application URL, you need to make some changes in Enterprise Application in Azure Active Directory as well.


Change Reply URL in Enterprise application in AAD from /sap/saml2/sp/acs/100 to SAP Fiori Launchpad /sap/bc/ui2/flp for both Public and Internal URL. Example, below

https://sleswd1.internal.cloudapp.net/sap/bc/ui2/flp

https://s4hanatesting.eastus2.cloudapp.azure.com/sap/bc/ui2/flp

References


Configuring AS ABAP as a Service Provider

Using Proxies

Tutorial: Azure Active Directory single sign-on (SSO) integration with SAP Fiori

Manipulating Header Fields

Single Sign-On with SAML 2.0

Using SAML 2.0 Authentication to Access Fiori Apps from the Public Internet

Regards,

Dennis Padia
10 Comments
Labels in this area