SAP on Azure: Single Sign On Configuration using SAML and Azure Active Directory for Public and Internal URLs

[dennispadia]

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 Unspecified, Transient, 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

[Ben]

Hi dennis.padia

Wow thanks for this detailed article. I also set up a Fiori (OnPrem) with MS Azure SSO and AppProxy and I know that the process is not trivial.

Do you maybe also happen to experience some CORS issues having a similar setup like me?

We have CORS issues after we leave the Fiori Launchpad (or other Fiori App) open until session timeout is reached, which happend after around 30min. Then the client sends a HTTP Request to https://login.microsoft.com/…./oauth2/authorize?… and we get following error message:

Access to XMLHttpRequest at https://login.microsoft.com/…./oauth2/authorize?… (redirected from <external AppProxy address>) from origin <external AppProxy address> blocked by CORS policy: Response to preflight request doesn’t pass access control check: No “Access-Control-Allow-Origin’ header is present on the requested resource.

I opened a SAP ticket and Support believe error is no Microsoft Azure (AppProxy) side.

Best regards,

Ben

[dennispadia]

Hello benkrencker

I have not used Application Proxy as my entire system is hosted on Azure. Application proxy provides single sign-on (SSO) and secure remote access for web applications hosted on-premises, which is not my case.

If you can check this article Understand and solve Azure Active Directory Application Proxy CORS issues which provides some options to resolve CORS issue. Option 5 in particular talks about the situation you are encountering.

Option 5: Extend the lifetime of the access token

Some CORS issues can't be resolved, such as when your app redirects to login.microsoftonline.com to authenticate, and the access token expires. The CORS call then fails. A workaround for this scenario is to extend the lifetime of the access token, to prevent it from expiring during a user’s session. For more information about how to do this, see Configurable token lifetimes in Azure AD.


Regards,

Dennis Padia.

[RolandKramer]

Hello Dennis

See also the Document - SAP First Guidance – Implement SAP BW/4HANA in the Azure Cloud were I have covered some of these Topic's as well ...

Best Regards Roland

[former_member764988]

Hi Dennis,

 

Very well written. I have used this article to configure SAML2 on a recently migrated system.

 

Thanks

Nitish

[immudiraj]

Hi Dannish

The blog is very information and helpful to understand the SSO set-up. We have issue which is some what relevant to your guide.

The SAP Application deployed on SCP is having login mechanism using app-router concept in SCP MTA project. This application is exposing services which need to be authenticated using SSO. SCP is configured with Microsoft Azure ADP as IDP in Trust configurations. All necessary configurations are done to establish trust on Azure ADP.

When we try to call the service URL as REST Call (in WordPress Portal which is also using Microsoft Azure ADP as IDP)then its not able to authenticate and its failing to login to system and output the data. We have tried the below options:

1. Send the access token generated while logging into WordPress site and send the token for service URL
2. Put an iFrame with Source as Service URL and tried to login, but we could not display the iframe as we had restrictions of using Iframe in non SAP (WordPress website page)

We tried to send the client ID and client credentials of SAP SCP Service Applications in Rest CALL, it did not worked.

Not sure what else is required to achieve this. If you need to know more about the issue, happy to share our configuration document.

Appreciate your input.

Thanks

Maddy

[guspatt1]

Hi Dennis,

nice blogs. I realise that this is over a year old now but I thought it still worth a comment.

The only issue I have with this is that it relies on the Gateway server to trigger the authentication dialogue, this means that the first HTTP call from the internet reaches the gateway server without being authenticated.

It is possible to bypass SAML with the right URL and (unless this is explicitly blocked) then a bad actor can get access to the Fiori Launchpad login screen. This may be low risk but it feels like someone could get a long way into the application stack without being challenged. Some WAF appliances have the ability to offload SAML authentication as soon as they recognise the URL (something I've used in the past) but I'm not sure that there is anything native in Azure that can do this. I'd be happy if someone could tell me otherwise.

Regards

Gary

[PaulBuettner]

Hey Gary,

you may block LogonScreen/Basic Auth whatever you don't like in the ICF nodes.

Tab Logon Data > Choose Alternative Logon Procedure and dismiss all entries in the list at the very end besides SAML2.

 

BR;

Paul

 

[former_member146669]

Hi Dennis,

Thanks for your blog which is very comprehensive.

By the way, the above solution fit for scenario of web-based (browser) SAP client only.

And SAML is not work for SAPGUI with Azure AD SSO.

 

How about SSO with Azure AD for SAPGUI (LogonPad) application? I could not find any other blog, page/documents mentioned about that....

All I can find is not appliciable for Azure AD but local windows AD only.

I suppose SSO3.0 should support SAPGUI SSO with Azure AD, right?

 

Regards,

Gary

[Mofizur]

Thank you for the great article.

 

We have similar situation and the desktop is workign as epxected using thsi particular method.

But is this scenario valid for App based Mobile applications? I thought SAML would require a browser and unfortunately our Mobile App is nto browser based. Any idea?

 

Thanks,

Mofizur

[marcelgerr]

Hello Dennis,

Could this setup also be used for SAP B1? I am curious to know the application of SAML SSO since we are struggling to get this working seamless.

Regards,

Marcel