Skip to Content
Technical Articles
Author's profile photo Oxana Junkereit

Configure SSO using Azure AD from the Internet for SAP Fiori (on prem) via Azure Application Proxy

There are many security considerations when exposing on-premises applications to the internet. Therefore, most clients keep their SAP Fiori apps accessible from the internal network only and provide VPN access for those use cases, when mobile access is required.

However, there might be some use cases for exposing Fiori apps to the internet, for example if you want a to address a wider user group, than those typically having access to the enterprise network ( i.e., business partners). Luckily, plenty of solutions on how to expose Fiori Apps to the internet exist.

One is to make use of proxy apps like Azure AD Application Proxy: https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy. The biggest benefit of using Azure app proxy consists in replacing the need for a VPN based access and not requiring to open inbound connections through your firewall for a specific app, as all inbound communication is rooted via the application proxy connector that is located within the enterprise network or rather the DMZ.

When enabling the use of SAP Fiori apps via Azure app proxy, you may also want to enable SSO, as this strengthens the secure access to your apps and reduces complexity for the users. It enables your also to refine your authentication process, for example if you would like to allow conditional access (only registered devices may log in etc.) capabilities or more that one factor to your authentication .

This blogpost does not focus on how to set up Azure app proxy for SAP Fiori, but rather the SSO configuration part, when you already configured Azure app proxy.

However, before explaining how to set configure SSO for Azure app proxy for Fiori, lets look a bit deeper on the authentication flow in this scenario as this helps better understand the final configuration and helps to eliminate configuration mistakes.

authentication%20flow

authentication flow

This diagram and authentication steps are based on Microsoft docs describing the general SSO mechanism between Azure Proxy App and a generic service provider (=SP) for SP initiated authentication flow (https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-configure-single-sign-on-on-premises-apps). An IdP (=Identity service Provider) initiated authentication flow is possible though, but the setup is a bit different than described in this blogpost.

  1. the user’s client (webbrowser) tries to reach the app proxy
  2. the application proxy redirects the request to Azure AD for (pre-) authentication
  3. in case of successful authentication in Azure AD the request is forwarded back to the application proxy
  4. the application proxy forwards the request to the SAP application server
  5. the SAML Service on the SAP system generates a SAML request and redirects it to Azure AD in order to fetch a SAML response (the request is proxied trough the app proxy)
  6. Azure AD returns the SAML response to the SAP application server via the Application Proxy Connector
  7. the SAML service on the SAP system validates the SAML response and signs in the user to SAP Fiori Launchpad

Now that you are familiar with the authentication flow mechanism, we can start configuring!

Step 1 – Enable SSO for SAP Fiori using Azure AD without app proxy for access form the enterprise network

There are plenty of good blogs for this (i.e. “Single Sign-On (SAML2) Configuration for SAP FIORI Application” or “Configure SAML based Single Sign-on for SAP Fiori and NetWeaver using Azure Active Directory”), so no need to discuss the exact procedure within this blogpost. If SSO for SAP Fiori works fine within the enterprise network, you can be sure that you’ve done the basics correctly and you have a solid configuration foundation for the next steps.

Step 2 – Create an Azure Proxy App for SAP for your SAP Fiori Launchpad

There is also good documentation (https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-add-on-premises-application ) on this, so I will not discuss the exact steps here. But please be aware that in order for the application proxy URL to work correctly, you have to use ONLY the host and port that points to the SAP Fiori Launchpad or its Alias but not the entire root string pointing to the Launchpad. So, if your Launchpad URL is https://<server>:<port>/sap/bc/ui2/flp, please publish https://<server>:<port>/ as the internal URL. The External URL can be a custom Domain, like https://myfiorilaunchpad-proxy.msappproxy.net. But for actually calling the URL for testing purposes, please put the published app proxy URL and the remaining root string pointing to the Fiori Launchpad back together https://myfiorilaunchpad-proxy.msappproxy.net/sap/bc/ui2/flp .

Azure AD Application Proxy configuration

And please do not forget to select “Azure Active Directory” in Pre-Authentication field (red box on the screenshot).

After testing the proxy app from the internet without SSO, you can be sure that your proxy app works before starting the SSO configuration for it. Do not forget that your test URL would be the external URL for the Azure app proxy (https://myfiorilaunchpad-proxy.msappproxy.net) + the root string to your Fiori Launchpad (/sap/bc/ui2/flp): https://myfiorilaunchpad-proxy.msappproxy.net/sap/bc/ui2/flp .

Step 3 – Update External URL in SAML configuration

Now please go back to the SSO configuration in Azure AD you did in Step 1 in order to update the Reply URL. For this you will need to use the external URL from your app proxy that you have configured in Step 2.

If your External URL (Step 2) is https://myfiorilaunchpad-proxy.msappproxy.net and the Reply URL was https://<server>:<port>/sap/saml2/sp/acs/200 you have to update the Reply URL to https://myfiorilaunchpad-proxy.msappproxy.net/sap/saml2/sp/acs/200 .

changing%20reply%20URL%20in%20Azure%20SAML%20tonfiguration%20to%20proxy%20reply%20URL

changing reply URL in Azure SAML configuration to proxy reply URL

After completing Step 3 you are ready to test your SSO configuration from the internet.

Please do not forget to test in a private browser window to verify that you’ve succeeded to set it all up correctly and not only used the stored cookies in your browser session 🙂 !

 

 

Assigned Tags

      20 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jose Ruz Polanco
      Jose Ruz Polanco

      Hi, first of all, great content.

      I do have a question. Is the Azure App Connector a replacement of the Web Dispatcher in your architecture? If not, where in your process would the WD be involved?

      Thanks

      Jose

      Author's profile photo Oxana Junkereit
      Oxana Junkereit
      Blog Post Author

      Thanks!

      No Azure App Connector does not replace the Web Dispatcher, as you might also want to use load balancing and other capabilities that Web Dispatcher offers.

      Azure App Connector is mainly used to root all inbound communication and does not require configuring inbound access through your firewalls, unlike for Web Dispatcher. So it as an additional security layer for your Fiori Internet Architecture.

      In our scenario we also used SAP Web Dispatcher, which is located "behind" Azure App Connector but still within the DMZ.

      Hope this helps!

      Author's profile photo Jose Ruz Polanco
      Jose Ruz Polanco

      Perfectly clear, thanks!

      Author's profile photo Jose Ruz Polanco
      Jose Ruz Polanco

      Hey I wanted to let you know that we have successfully configured this but I do have a question if you don't mind.

      Once that we set on App Proxy the internal URL for the SAP server like: https://<server>:<port>/

      Doesn't that give external access to the entire SAP server? Say that the user types: https://myfiorilaunchpad-proxy.msappproxy.net/sap/bc/webdynpro/sap/<wd_app> 

      Or even for an OData, I get the roles could stop them, but would they get access? Because in my case they do have access even when I only wanted to provide access to flp alone.

      Have you ran into this? If so, what would you recommend if not too much to ask?

       

      Author's profile photo Oxana Junkereit
      Oxana Junkereit
      Blog Post Author

      Happy you managed that!

      Actually the SAML2 configuration only provides authentication and not authorization, so it won't touch roles and authorizations that you've already configured for that user...

      However, I guess you wanted to redirect to a webdynpro app and not the entire FLP right? In order to achieve this you need to configure IdP initiated SSO (and not SP initiated SSO) and provide the correct relay state mapping to your webdynpro application. Maybe this blogpost might help you: https://blogs.sap.com/2019/02/19/what-is-relaystate-in-saml-and-how-to-configure-relaystate-on-as-abap/

      Author's profile photo Kashyap Shah
      Kashyap Shah

      Hi Oxana,

      Thanks for the blog as this is my exact setup that I am trying to achieve since last year with no luck.

      Unfortunately, I had this exact configuration already done and still SSO on Mobile device via App Proxy doesn't work. Although, it's exactly the same setup that I am trying to achieve, I'll elaborate for you to pick any holes.

      I have S/4HANA backend system with embedded Fiori and a Web Dispatcher (webdisp.program.region.company.local) sitting in front of that.

      I have configured SAML2 SSO using a Web Dispatcher link and SSO works fine internally when accessed using https://webdisp.program.region.company.local:44470/sap/bc/ui2/flp?sap-client=700

      I also have published Azure App Proxy URL and access from Mobile device using App Proxy (without SSO) works fine using https://programbe-company.msappproxy.net/sap/bc/ui2/flp?SAP-Client=700

      Now, for SSO to work on a Mobile device, I have got Azure App Proxy URL (https://programbe-company.msappproxy.net/sap/saml2/sp/acs/700) added as an additional Reply URL (and marked as Default) to the Azure Enterprise Application for SSO.

      As soon as above step is done, my SSO stops working internally and on Mobile device, even the login page doesn't load.

      On checking SAML2 trace, I see below error while accessing it using App Proxy URL or Web Dispatcher URL:

      SAML20 SP (client 300 ): Destination from Response https://programbe-company.msappproxy.net/sap/saml2/sp/acs/700 must match the actual URL where message was sent - ACS endpoint https://webdisp.program.region.company.local:44470/sap/saml2/sp/acs/700 or application URL(depending on configuration)
      
      
      

      I don't have much idea about settings on Azure side as I am from SAP Basis workstream with limited access to Azure portal. But one thing that I noticed different compared to point 6 on https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-add-on-premises-application

      is that
      Use HTTP-Only Cookie
      Use Secure Cookie

      are set to No

      Also, another observation is that when I try to access the application internally using given web dispatcher link, the URL in the browser turns to app proxy URL. Please note that this was the case even when web dispatcher URL was ticked as Default under Reply URL on Azure.

      It would be great if you could help as every other channel has failed.

      Thanks.

      Best Regards,
      Kashyap Shah

      Author's profile photo Oxana Junkereit
      Oxana Junkereit
      Blog Post Author

      Hi Kashyap,

      unfortunately, I cannot debug your issue, therefore please refer to SAP AND Microsoft support for your issues. (We were also facing many issues along the way to our final setup and the support teams from both SAP and MS helped a lot!)

      But as you've asked some ilicit advice from my side 😀

      • as your testing on a mobile device, I encourage you to test in a secure browser session on a laptop or PC, so that you can be sure that the mobile browser versions or setting on your mobile device do not impact your tests
      • please check with your network team about firewall settings, they might block some URLs from properly communicating with your proxy service
      • the setting you mentioned from 6 on https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-add-on-premises-application probably have to be put on YES for both, but feel free to create testcases and to document (a lot)

      Wish you the best of luck!

       

      Author's profile photo Kashyap Shah
      Kashyap Shah

      Thanks for your advice Oxana.

      So far I haven't got any success with SAP. I shall try Microsoft channel as well.

      I hope to resolve the issue this year and provide an update here.

      Cheers.

      Author's profile photo Oxana Junkereit
      Oxana Junkereit
      Blog Post Author

      I also guess the proxy issues are more on MS side... what helped us in the end was setting the pre- authentication to "passtrough" in App Proxy settings... but this might be our special case using additional loadbalancers in front of SAP Web Dispacher... just as an additional idea.

      Author's profile photo Kashyap Shah
      Kashyap Shah

      Thanks again Oxana for the hint. But we don't have any load balancer in front of Web Dispatcher, so hopefully standard "Azure Active Directory" for Pre Authentication should work for me.

      I just have one problem now that on Azure SSO enterprise application, I have got Two Reply URL configured:
      Internal/Web Dispatcher and
      External/Azure App Proxy

      with External marked Default. So, the issue is that regardless of which host I use (Web Dispatcher or App Proxy) to access the system, the response is returned to the default Reply URL which is of App Proxy. SSO doesn't work in both case.

      Now above behavior is with following SAML2 setting:

      If I change Assertion Consumer Service from Default to "ACS URL", SSO via Internal host work fine but then looking at URL, it looks like the response is returned to the Web Dispatcher regradless of what's used to access the system and so the access fails when it's via App Proxy URL.

      I would appreciate any hint on as to how do I get response from Azure returned to Web Dispatcher if access is originated from there or App Proxy in case access is originated from there?

      Did you make use of any condition in the redirect.txt file on the Web Dispatcher, that's set using the parameter icm/HTTP/mod_1 by any chance?

      Thanks.

      Author's profile photo Kashyap Shah
      Kashyap Shah

      Hi Oxana Junkereit,

      Do you provide any additional option as part of application URL (mainly configured ACS URL and/or Azure application identifier)? Or is SAP configured in any way to send above options to Azure as part of authentication request?

      Thanks.

      Author's profile photo Oxana Junkereit
      Oxana Junkereit
      Blog Post Author

      no other than mentioned as in this picture

       

      or which URL exactly you mean?

       

      Author's profile photo Kashyap Shah
      Kashyap Shah

      I meant to ask the URL used to access the application. Whether as part of that you (can) provide any option like AssertionConsumerServiceURL, identifier, etc.

      For example, based on my problem statement above, my URL (with no option) that I use to access the application is:

      https://webdisp.program.region.company.local:44470/sap/bc/ui2/flp?sap-client=700
      Author's profile photo Oxana Junkereit
      Oxana Junkereit
      Blog Post Author

      ok, I see, as described above in the blogpost:

      the URL would be the external URL for the Azure app proxy (https://myfiorilaunchpad-proxy.msappproxy.net) + the root string to your Fiori Launchpad (/sap/bc/ui2/flp) (+ parameter spnego=disabled) so: https://myfiorilaunchpad-proxy.msappproxy.net/sap/bc/ui2/flp?spnego=disabled)

      (actually we shortened the URL as to https://myfiorilaunchpad-proxy.msappproxy.net/flp via customized FLP URL https://help.sap.com/viewer/17ae0e97e0fc424a9c368f350c0ba6bd/2.10/en-US/c944dc71fc7d49b4a1239a4231563c80.html)

      Author's profile photo Kashyap Shah
      Kashyap Shah

      Hi Oxana,

      Are you able to help with one more setting on Azure Proxy App side as to what's set for circled in Green in the screenshot below please:

      Thanks.

      Author's profile photo Micky Barzilay
      Micky Barzilay

      Dear Oxana,

      Really nice post.

      I'm going to appreciate your support.

      After following your post I'm receiving the following error:

      SAML20 SP (client 400 ): Destination from Response https://fiori2-xxxxco.msappproxy.net/sap/saml2/sp/acs/400 must match the actual URL where message was sent - ACS endpoint https://sapserver.domain.com:8001/sap/saml2/sp/acs/400 or application URL(depending on configuration)

      And the Fiori login page is shown.

       

      Any idea what I have missing?

      Micky

       

       

      Author's profile photo Oxana Junkereit
      Oxana Junkereit
      Blog Post Author

      Hi Micky,

      unfortunately, I cannot debug your issue, therefore please refer to SAP or/and Microsoft support.(my hint here would be that in your SAML2 configuration the ACS URL does not mach the one you configured in Azure AD...)

      Best of luck!

       

       

       

      Author's profile photo Rikardt Louw
      Rikardt Louw

      Hi All

      Has anybody been able to resolve the ACS different endpoint URL issue.

      So if you have one domain that is your proxy  https://proxy.com and the other your real domain https//realdomain.com it seems you can have two outcomes/scenarios at play.

      Scenario 1: You use the proxy.com as your ACS destination  (SAML Redirect Url ) . It will be rejected by SAP for not matching your realdomain.com. This proxy domain is also added to the SAML Response.

      Scenario 2: If you try and redirect from the  proxy.com back to the realdomain.com you get blocked with the relaystate error which is  normally due to the domains being different.

      It seems to be a Chicken and Egg issue.

      Thanks

      Author's profile photo Oxana Junkereit
      Oxana Junkereit
      Blog Post Author

      Hey Rikardt,

      SAP Netweaver  expects the Reply URL to be the Internal URL, so you'll need to either use custom domains to have matching internal and external URLs or use your load balancer or another proxy located in the DMZ to do the job for you... (please refer to MS documentation on that matter: https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-configure-single-sign-on-on-premises-apps )

       

      Author's profile photo Rikardt Louw
      Rikardt Louw

      Hi Oxana

      Appreciate the quick response.  I will take a look at he custom domain option.