Hello Boudewijn,

It's not CORS that prevents these interactions, it's the Same Origin Policy (SOP) that all modern browsers use. CORS is actually the mechanism through which you can poke holes in this SOP to allow for some exceptions.

CORS is by itself will not be enough, because CORS only governs whether a request is allowed to be sent or not, but browsers also apply this policy to determine if cookies can be sent. So, cookies will also need to be configured to be allowed to be sent on cross origin requests. In doing so, the browser will mandate HTTPS, which is fine, but it still won't work in incognito windows, until the user flips the the radio button to allow third party cookies.

So due to all of these issues and the fact that it is simply a bad practice for security to begin with, we don't advocate for a solution like this. We've also found that it's usually not necessary to use a solution like this either. Can you elaborate on your use case regarding integration? Is there a web application hosted by a third party that would like to send requests to Indicium?

• If it's not a web application, then there is no issue.
• If it's not hosted by a third party, then why not host it on the same domain in Azure?
• If it is a third party web application, then this is indeed difficult

To add to my answer, if your situation is indeed the third case, then I don't think there's anything wrong with using a proxy, I would say that this is the correct solution. The proxy can be limited to only send requests to Indicium on Azure.

Hi Vincent,

Thanks for your elaborate answer!

It is indeed the third option, a connection to a third party web app. According to our partner, “security auditors will frown upon a proxy-solution”.

Do we have a recommendation for a proxy to use? I did get the impression the current solution was cobbled together (explaining the frowns..).

I imagine a proxy that integrates to Azure would be able to use the credentials store in Azure, so that that can be configured as a regular IAM user, with roles applied to have access to just the functionality it needs.

According to our partner, “security auditors will frown upon a proxy-solution”.

I honestly don't see why, perhaps they could elaborate on this. To be clear, I'm talking about a self-hosted, reverse proxy. It can simply be companydomain.com/indicium which performs HTTP passthrough to azuredomain.com/indicium.

As for what to use as a reverse proxy, you can configure IIS to be a reverse proxy for instance. We have documentation on that here. You could also use nginx or another webserver.

I'm not sure about storing the credentials in Azure and having the reverse proxy supply them, this doesn't seem like the most obvious solution to me, if it's even possible. A reverse proxy doesn't really integrate, it just forwards requests and responses. If it doesn't feel secure enough to have the client application handle the credentials for the requests to Indicium, then it is an option to have the reverse proxy inject the credentials into requests, but it would probably be some kind of configuration of server/environment variables on the web server then. I can't really provide a tailored solution here.

Thanks again.

It should give some handhelds for developing the service.

I'll take it up with him and clarify here in case I misunderstood what he explained to me earlier. In that case I'll be sure to provide some more background as well!