Skip to main content

Dear all,

As per subject I’m trying to setup the SSO on the Universal GUI for part of my users and facing an issue. 

The documentation mentions the setup of the SSO from Thinkwise perspective which is sufficient, but there is no documentation at least for the setup for Azure/AWS/Google perspective what is actually needed.

My Setup:

  1. I have a Resource group (RG) called TEST
  2. I have a VNET for the RG
  3. I have SQL server and App service in the VNET
  4. I have a Front Door having the default *.azurefd.net and my custom domain
  5. The Front Door points to my App service and redirects traffic correctly.
  6. The Indicium and Universal are installed on the App service.
  7. The whitelist of client redirect URLs in IAM is my custom domain only.

For the SSO:

  1. I have done the App registration
  2. I have added the new configuration in App Service for the OpenID Microsoft authentication
  3. I have added my custom domain on App service

Problem I face and would like some input is that,

The App registration requires that the Redirect URIs specified are pointing to the App Service default URI being the *.azurewebsites.net and not my custom domain that I have added additionally. How can I have my custom Domain called in the App registration ?

Even if I allow to use only the *.azurewebsites.net as the only URL for the universal and indicium, I can only login with Microsoft only in Indicium, I cannot access the universal GUI. How can I redirect to my custom domain universal GUI?

*Note that local users works fine and can login even through indicium login page.

**The login is very inconvenient as I need to go through the indicium login instead of Universal GUI login. You are unable to use the customization of the custom.css .

Thanks to @Vincent Doppenberg the issue for having the custom domain being a redirect URI for the App Registration is answered and it is working.

The solution was to have the reverse proxy defined for the setup when using Microsoft Azure Front Door:

  {
    "name": "ReverseProxy__AllowedHeaders__0",
    "value": "All",
    "slotSetting": true
  },
  {
    "name": "ReverseProxy__Enabled",
    "value": "true",
    "slotSetting": true
  },
  {
    "name": "ReverseProxy__KnownNetworks__0",
    "value": "147.243.0.0/16",
    "slotSetting": true
  },
  {
    "name": "ReverseProxy__KnownNetworks__1",
    "value": "2a01:111:2050::/44",
    "slotSetting": true
  }

The above are standard for any implementation with this setup proposed in Documentation and should be part of the common documentation. 

Regarding my second concern using Indicium login instead of Universal, I will raise it as an idea to have the functionality merged to Universal GUI. With that we eliminate the loss of the custom.css we might have implemented on the Universal GUI. 

Hello mperrot,

Thank you for posting the final that solution that we have discussed in the corresponding ticket here as well. This will be helpful for other people running into this issue.

I will refer our documentation team to this topic to have our documentation improved. It is indeed not very obvious right now how to get an Azure Front Door setup to work properly.

For the sake of completeness, the configuration that mperrot has posted above translates into the following configuration in the appsettings.json:

"ReverseProxy": {
   "Enabled": true,
   "AllowedHeaders": [
      "All"
   ],
   "KnownNetworks": [
      "147.243.0.0/16", 
      "2a01:111:2050::/44"
   ]
}

Whenever Azure Front Door is used in front of Indicium Universal, this configuration will be necessary in the appsettings of that Indicium Universal. The IP spaces defined in KnownNetworks should be always be the same for Azure Front Door, so these are not situational.

The above answer has just been added to the Thinkwise documentation. See: Load balancing with Azure Front Door.

Terms & ConditionsCookie settings