Skip to main content
Solved

Deployment on Azure with custom domain and OIDC redirect url

  • December 5, 2024
  • 4 replies
  • 83 views
R
Vanguard
Forum|alt.badge.img+4

Hi,

We have a Thinkwise deployment on Azure with the specific Azure subdomain url. Besides that we have a custom domain that will be used by the end-users. The end-users will make use of AusweisApp, which is similar to DigiD in the Netherlands. When the end-user tries to access the application using the custom domain, the external providers authentication page is triggered. What however happens is that not the custom domain is used for the redirect url, but the Azure domain name. The redirect should go back to the custom domain. In de config.json the custom domain is configured. Also when logging on, in the Options → Metaserver url, the correct url is shown.

Any idea where this goes wrong and where we should configure the use of the correct redirect url?

Best answer by Vincent Doppenberg

Hello ​@Robert Wijn 2,

When using any kind of reverse proxy, such as an Azure Application Gateway or an Azure Front Door, in front of Indicium, you will need to configure the corresponding Reverse proxy settings in Indicium’s appsettings. This requirement actually has no relation to OIDC specifically, it is necessary for multiple reasons. I’m assuming that you’re either using Azure Front Door or Azure Application Gateway:

Azure Front Door

We have some specific documentation for Azure Front Door, which you can find here.

 

Azure Application Gateway

According to this Microsoft documentation, the Azure Application Gateway does not send an X-Forwarded-Host header by default, but it does send an X-Original-Host. So, if you’re using an Azure Application Gateway, you will have to add the following to the Reverse proxy settings in Indicium’s appsettings:

"CustomHeaders": {
   "XForwardedHost": "X-ORIGINAL-HOST"
}

Furthermore the IP-range defined in KnownNetworks may have to be changed to the correct IP-range for your Application Gateway.

 

I hope this helps.

View original
Did this topic help you find an answer to your question?
This topic has been closed for comments

AndreKemmeren
Captain
Forum|alt.badge.img+3

The redirect URL is configured on the OIDC side of things.

So it's likely a misconfiguration in AusWeisApp

R
Vanguard
Forum|alt.badge.img+4

Hi Andre,

Thanks for the reply, but I don't think so. The AusweisApp is receiving the redirect-url from Thinkwise which should be generated based on the meta server which is the custom domain in our case. So the callback url sent to AusweisApp is not correct (being the Azure domain). I can imagine that maybe some Azure configuration is involved.

V
Moderator
Forum|alt.badge.img+4

Hello ​@Robert Wijn 2,

When using any kind of reverse proxy, such as an Azure Application Gateway or an Azure Front Door, in front of Indicium, you will need to configure the corresponding Reverse proxy settings in Indicium’s appsettings. This requirement actually has no relation to OIDC specifically, it is necessary for multiple reasons. I’m assuming that you’re either using Azure Front Door or Azure Application Gateway:

Azure Front Door

We have some specific documentation for Azure Front Door, which you can find here.

 

Azure Application Gateway

According to this Microsoft documentation, the Azure Application Gateway does not send an X-Forwarded-Host header by default, but it does send an X-Original-Host. So, if you’re using an Azure Application Gateway, you will have to add the following to the Reverse proxy settings in Indicium’s appsettings:

"CustomHeaders": {
   "XForwardedHost": "X-ORIGINAL-HOST"
}

Furthermore the IP-range defined in KnownNetworks may have to be changed to the correct IP-range for your Application Gateway.

 

I hope this helps.

R
Vanguard
Forum|alt.badge.img+4

Hi Vincent,

Thanks for the information! This set us on the right track and eventually to the solution.

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings