CORS for App Proxy
There should be CORS setting available on App Proxy just like we have the CORS available for App Services.
Making calls from Azure Apps into an Azure App Proxy App is a very common scenario, especially when on-prem applications are surfaced externally using App proxy.
We are looking at enabling a feature that focuses on supporting CORS preflight requests between two applications. This works by allowing you to configure the response and have App Proxy handle it on behalf of the app.
A pre-requisite for this feature to work is that the user must be able to authenticate into the second application in order to avoid a CORS issue from the login flow into the second app.
To avoid this the user will have to make sure they have already accessed the 2nd application before the CORS request, and has valid credentials. This should work for wildcard apps and can also be achieved by adding a fake link / image to the 2nd application in the first application.
We would love to get your feedback on this requirement and if this is something that will fit your use case.
Martin Ericsson commented
Any updates on the ETA for this?
Florian Scandella commented
We are currently building a SPA website accessing an internal Web API through Azure AD Application Proxy. We are now hitting this roadblock, because the API Requests need an Authorization Header to go through the Proxy. A preflight CORS request is sent and blocked with 403 by the Proxy. Azure lets us register a SPA an let me grant impersonation rights to the proxied API without any warning that it will not work.
Would your suggested feature fix our issue?
Sebastian P. commented
Anything new regarding this topic?
Jeff Johnson (IT) commented
Trying to Proxy Oracle APEX internally. It says need ProxyPreserveHost set for CORS.
Visceglia, Felice commented
Echoing what many others have said, it is a bit silly to not have a solution for this, giving how common CORS request flows are. We, too, need to use AAD App Proxy for SharePoint on-prem. Our SharePoint site calls an internal API cross-origin. If we enable AAD Pre-Auth for the API, that introduces the CORS issues detailed here. If we switch to passthrough, in addition to the obvious security implications, we still have issues because that disables Azure SSO (e.g., the AAD App Proxy Connector will no longer act as a delegate for negotiate-kerberos auth). I do not think the solution outlined by MS response here is sufficient for these common use cases.
We are using sharepoint online, and call an onprem API, While in our office it works fine as we have contol of the API server and have added the access-control-allow-origin header, but externally we are attempting to use the Azure AD app proxy, which is generating the CORS error when the browser hits it. Please allow us to add CORS headers to the app proxy
It might be helpful if you can define granular access and filter rules (for CORS).
So you can disable Pre-Auth for a specific call (CORS Preflight = HTTP Options Call to a specific service)
Frechette, Pierre commented
For now, in the case of our SPfx webpart, we're redirecting the users to a redirect page on the proxy. We inform them we first need to "authenticate their request". This redirect page will simply redirect the user back to the page with the SPfx webpart. This way, the proxy authentication process takes place and subsequent XmlHttpRequests have the necessay authentication cookies for the proxy. Not ideal, but it works.
Very much required here as well, cannot cross reference the data between our own servers due to this limitation.
Not sure if the above 5 Nov proposed solution improves anything.
The requirement of the proposal of going to the second application first is our current workaround without CORS support in app proxy.
The above proposal pre-requisite, bypasses the CORS issue, not solves it
application A and B are published through app proxy on domains A and B
1.) access application A on domain A
2.) application A does ajax call with origin header to application/web services B on domain B
3.) App proxy sees no azure app proxy cookies for domain B, and issues 302 redirect to login.microsoft.com without CORS headers
4.) Browser doesn't follow redirect
2.) access application B on domain B. browser caches app proxy cookies for this domain
1.) access application A on domain A
2.) application A does ajax call with origin header, with app proxy COOKIES, to application/web services B on domain B
3.) App proxy sees azure app proxy cookies for domain B, and app proxy passes through the request to domain B
the issue is the browser is not trusting login.microsoft.com in a AJAX request introduced by app proxy.
I think the proposal should be, when app proxy handles a request to a app domain that contains a Origin header, but has not authenticated, the issued 302 redirect to login.microsoft.com should contain the CORS Allow in the response
> We would love to get your feedback on this requirement
For our use case it sounds promising. The only thing to mention is that it´s not sufficient to load an image from the 2nd application to trigger SSO to there. You need an iframe loading a (dummy) webpage from the 2nd app.
Frechette, Pierre commented
Same as everyone lately on this thread. Total blocker to expose on-prem services via proxies that require CORS. The redirects to and from login.microsoftonline.com or device.login.microsoftonline.com seem to be breaking the flow. We have an SPfx webpart on sharepoint.com trying to do XmlHttpRequests to a proxy, but the whole thing fails because of this.
Interested in understanding the statement "This should work for wildcard apps and can also be achieved by adding a fake link / image to the 2nd application in the first application". Our testing as shown that navigating to the proxy in a different browser tab to obtain the required 'AzureAppProxy*' cookies prevents the redirects to login.microsoftonline.com; subsequently refreshing our page with the SPfx webpart then works. I understand the issue is complex since it requires checks to the AAD app as well as potential Conditional Access checks. Multiple redirects seem to be involved with user authentication and can't seem to play well with XmlHttpRequests. Help is very much appreciated. Re-writing the app to leverage Azure API Management or some other kind of data access is not in the cards in the short term.
any update on this feature. This is a major roadblock to us while accessing On-premise services securely from O365 SharePoint online with AD Authentication.
can you tell us what is the ETA for this feature?
Matt Froese commented
Any update? This has been causing us major issues since switching to App Proxy.
Hi Azure AD Team,
Is there any update regarding the release date of this feature?
We too have a SaaS that needs to do a CORS access to our on-premises server which is exposed through Azure AD App Proxy with pre-auth enabled. We're getting 403 errors when CORS pre-flight requests are being sent. It would be great if there's a way to allow such traffic to passthrough
any update on this?
We want to expose multiple RESTful APIs currently on-prem through Azure AD App Proxy to be consumed by various SPA's. On-prem works great, and the Azure AD App Proxy works to expose the SPA, but gives a 403 error when the CORS Pre-flight request fires. This prevents the SPA from gaining access to the APIs. Since the APIs in question already use Azure AD for authentication and authorization, I wonder what the risk in allowing passthrough for the Azure AD App Proxy Pre-Authentication to fix this issue?
We want to use a SaaS which needs to do a CORS access to a on-premise server.
This SaaS Application needs to run on mobile devices and on-premise. Because of the limitation of the app Proxy this doesn't work.
Our SharePoint Online portal leverages Application Proxy to consume various on premise resources. We currently use the hacked iFrame approach for authentication for all requests going thru App Proxy to get around this limitation. Its cumbersome and a maintenance nightmare. There's also unnecessary repeated behind the scenes activity/load in the browser until the user is authenticated. This needs to be looked at and addressed immediately before it becomes a major development hassle.