Configure SSO using Azure AD from the Internet for...

Xenia · ‎01-13-2022

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 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...). An IdP (=Identity service Provider) initiated authentication flow is possible though, but the setup is a bit different than described in this blogpost.

the user’s client (webbrowser) tries to reach the app proxy

the application proxy redirects the request to Azure AD for (pre-) authentication

in case of successful authentication in Azure AD the request is forwarded back to the application proxy

the application proxy forwards the request to the SAP application server

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)

Azure AD returns the SAML response to the SAP application server via the Application Proxy Connector

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-... ) 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 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 🙂 !

jruz · ‎01-19-2022

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

Xenia · ‎01-20-2022

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!

jruz · ‎01-20-2022

Perfectly clear, thanks!

kashyap_shah3 · ‎02-01-2022

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-...

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

Xenia · ‎02-02-2022

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-... 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!

kashyap_shah3 · ‎02-02-2022

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.

Xenia · ‎02-02-2022

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.

kashyap_shah3 · ‎02-04-2022

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.

kashyap_shah3 · ‎02-14-2022

Hi oxana

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.

Xenia · ‎02-15-2022

no other than mentioned as in this picture

or which URL exactly you mean?

kashyap_shah3 · ‎02-15-2022

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

Xenia · ‎02-16-2022

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/c944dc71fc7d49b4a1239a423156...)

kashyap_shah3 · ‎02-23-2022

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.

mki_barzilay · ‎03-16-2022

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

Xenia · ‎03-17-2022

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!

rikardtlouw · ‎06-30-2022

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

Xenia · ‎06-30-2022

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... )

jruz · ‎06-30-2022

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?

Xenia · ‎07-01-2022

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-ab...

rikardtlouw · ‎07-07-2022

Hi Oxana

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

Mofizur · ‎12-19-2022

Hello Oxana,

I have the exact same scenario

Access SAP Fiori apps from Internet using Public URL.

SAP Fiori apps should also be accessible from Intranet directly using SAP Web Dispatcher URL.

For both communication (Internet and Intranet), we want SSO to be enabled.

We have SAP NW backend and we have SAP Webdispatcher and we have configured an Azure App Proxy to facilitate this requirement and when I am disabling the SSO then from Internet , we are getting the FIORI login page which makes me believe that the initial setup is good.

However when we enable SAML based SSO and user hits https://XXXXXX-XXXX.msappproxy.net/sap/bc/ui2/FLP/FioriLaunchpad.html from Internet, first of all he / she gets a certificate error because the hostname in the URL is getting changed from the external to internal.

Any idea what might be getting wrong?

Thanks,

Mofizur

Xenia · ‎12-22-2022

Hey Mofizur,

als with Rikardt please check the following:

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... )

Best of luck!

catia_silva · ‎02-02-2023

Hi oxana

thank you for your post. It is very nice.

We have the exact same set up as you described.

I have an additional question: what are the recommendations if we would like to provide a different external link/URL to access a specific Fiori App instead of all the Fiori Launchpad?

I really appreciate your opinion on the topic.

Thanks.

Xenia · ‎02-02-2023

Hi Catia,

thank you!

You can concider RelayState Mapping to your Fiori app for that matter. Although then you will need to configure IdP initiated SSO... Please refer to this blogpost by Mateus for getting an idea: https://blogs.sap.com/2019/02/19/what-is-relaystate-in-saml-and-how-to-configure-relaystate-on-as-ab...

Good luck!

catia_silva · ‎02-08-2023

Hi oxana,

thanks for your answer and clarification.

Anyway, looking to Hannes Defloo post ( Considerations and Recommendations for Internet-facing Fiori apps | SAP Blogs ), for this scenario we will go for a Application Gateway as we would like to expose the App to the Internet.

Thank you.

former_member615507 · ‎02-24-2023

Hello Mofizur,

Try it with the setting that you take out all checkmarks except this one.

Best regards

Umut

former_member615507 · ‎02-24-2023

Hello Oxana,

A really great post!

Question, why should the app proxy be in the DMZ? I would put it next to the SAP system, but at least not in the DMZ.

The App Proxy is not accessible from the Internet. The App Proxy establishes a connection to the Internet in the same way as an SAP system, e.g. via an Internet proxy.

Because the DMZ is exposed to higher risks, I would not place the App Proxy in the DMZ, but next to the SAP system.

In this constellation, I would also not place the Web Dispatcher, which is located in front of the SAP backend, in the DMZ for the same reason. Maybe even an ASCS embedded installation of the Web Dispatcher would be sufficient, depending on the requirements.

Best regards,

Umut

Mofizur · ‎02-24-2023

Hey oxana

Thank you for resonding!

I got this sorted out by using Azure Applicaiton gateway rather than using Azure App Proxy. AppGateway with SAML is working as expected for all of my above scenarios.

Thanks,

Mofizur

Mofizur · ‎02-24-2023

Hello umpa

Thank you for resonding!

I got this sorted out by using Azure Applicaiton gateway rather than using Azure App Proxy. AppGateway with SAML is working as expected for all of my above scenarios.

Thanks,

Mofizur

Xenia · ‎02-27-2023

Hi Ümüt,

Thank you for your feedback and thoughts!

As always the setup depends on your business goals. In our case we had the need that business partners are able to acess the proxy app from the Internet and therfore decided for this setup. Security wise I also do not really like the Idea of exposing Fiori Apps, that are hosted on promises, to the Internet. But this is what the client wanted and we made sure they get a setup that is as secure as possible.

Best,

Oxana

Summitt12 · ‎03-22-2024

@ kashyap_shah3

We are facing simliar SSO issue from Internet to Fiori

Did you managed to resolve it

Regards

MB

Summitt12 · ‎03-22-2024

We followed the steps, Gateway hub Fiori is asking for Logon details for both internal and external network

SSO is not working from External URL to Fiori backend (Gateway)

Has anyone been able to make sso work