Skip to main content

Hello,

I am looking for a robust solution to make the Universal GUI accessible outside our corporate network.

Currently, we are using Azure Application Proxy (AAP) to achieve this. Our goal is to avoid exposing our on-premises (web) servers publicly. With AAP, users must first log in with their Microsoft account before they can access the URL for the Universal GUI. After logging in with AAP, this authentication can be used to log in to the Universal GUI/Indicium by configuring Microsoft as the OpenID Provider. This way, after clicking "Log in with Microsoft," users are immediately directed to the Universal GUI.

The issue we're facing is that the AAP authentication expires after a certain period, but the Universal GUI does not recognize this expiration. This results in various error messages and blank pages, and users have to press Shift + F5 to be redirected to the Microsoft login page. This workaround is problematic for mobile devices, as Shift + F5 is not available, making it impossible to add the app as a PWA on iOS, for example. We have had extensive contact with Thinkwise about this (6846S), but it seems that this issue cannot be resolved when combined with Azure Application Proxy.

Therefore, we are now considering setting up a reverse proxy server to overcome these problems. Although the documentation provides some guidance on how to configure this, I am interested in hearing from other customers who have implemented a similar setup. Searching through the community has given me some insights, but these do not fully align with our situation (e.g., everything already hosted in Azure).

How do you handle this, especially from a security perspective? Ideally, we would like users to authenticate via Microsoft before the Universal GUI loads, ensuring that the server is not exposed without prior authentication.

Thanks

Hi all,

I’d like to share some more technical details from the ticket which could be relevant to the overall picture.

 

When authentication with AAP expires, the API calls from the GUI do not receive a typical 401 - Unauthorized when the authentication has expired. This is normally the signal for the GUI that the session has expired and re-authentication is required.

Instead, the calls receive a 302 - Found (a temporary redirect) from AAP. The rerouted request points to the Microsoft login page. This would work great for a regular webpage, where the user gets redirected to the Microsoft login page when a webpage is requested. However, API calls done in the background are focused on data transfer, not showing a web page.

On automatically following the redirect, a subsequent browser security validation (CORS preflight) fails because the domain where the GUI resides is not allowed to directly interact via API calls with the Microsoft login page. This causes the various error messages. 

It is difficult for the Universal GUI to prevent following these standard redirects which are essentially performed by the browser itself and are in most cases desirable. Detecting a request failed because browser security measures is also difficult to detect and is not a guarantee that the session has expired.

 

I hope this sheds some light on the technical details of the challenges when using AAP and why this issue is not something we can easily resolve in the GUI.

Intercepting any 302 - Found response from AAP on the Indicium service endpoint and instead returning a 401 - Unauthorized would be a solution but will require extra effort in the infrastructure. This is not something that can be done directly from the Thinkwise Platform.

 

Note that there is another drawback with AAP - Websockets are currently not supported. This may impact progress during task execution and import/export/mass-update and possibly future capabilities as well.

Thank you, Anne, for the additional technical information.

Hopefully, other customers have a solution. If you prefer not to share publicly due to security reasons, feel free to send me a private message.

​​​@Anne Buit , 

In addition to the above case...

A sysadmin noticed me that AAP may only be used by users with a valid Microsoft account, which will not always be the case, especially when external/anonymous users also have access to applications.

https://learn.microsoft.com/en-us/answers/questions/1229692/azure-ad-application-proxy-licensing

Is there any, easy to implement, alternative for AAP? 

 

We have implemented Azure Application Gateway, this would fit your requirements.

 

We will likely transition into Azure Frontdoor, this also grants added security.

Thank you Andre, 

This sounds good to me, we will investigate further on this.

Terms & ConditionsCookie settings