Custom login screens with different default Login settings

Related products: Universal GUI

As a follow up on this conversation: it would be great if there would be a simple way to create multiple custom login screens for the same Application and Infrastructure. 

This way we could differentiate login flows for different ‘types’ of users in our organization (as a direct customer of Thinkwise), for example:

  • Internal users with Azure AD account are automatically redirected to the Microsoft login screen, specific for our Tenant in order to ensure our MFA/Conditional Access policies
  • Internal users without an Azure AD account are automatically redirected to the Local login screen
  • External users with a generic registration at Microsoft / Google are automatically redirected to the login screen with both Microsoft (common) and Google as login options

In addition, I believe this could be of great added value for ISV's as well, whereby they can offer their customers the ability to use a tailored Login screen and use their customer-specific OpenID provider.

Having to run multiple IAM databases kinda destroys the idea of Intelligent (centralized) user/Application Management and is overkill for such a relatively small-scoped feature. 

NewOpen

@Anne Buit @Jasper since multiple customers are asking for a solution like this, and we ourselves need it for our vessel staff too by end of this month: would it be possible to plan this for Release 2023.2?


@Anne Buit I gave it a bit more thought and I am wondering if a temporary workaround could be created that might serve our most urgent needs at this stage, as well as those of @Bas and @mperrott: add a Universal GUI config.json parameter that basically causes the Universal GUI to ignore the IAM OpenID setup.

  • Universal GUI 1: This would cause the Universal GUI app with this ignore parameter to simply show it’s own (local) Login screen: suitable for the users who require Local login
  • Universal GUI 2: The second Universal GUI app without the ignore parameter would still redirect to Indicium to show the OpenID login option (with or without the Local login button, based on the IAM setting)

@Bas @mperrott could you confirm if this would work for your scenario for the time being?


@Anne Buit I gave it a bit more thought and I am wondering if a temporary workaround could be created that might serve our most urgent needs at this stage, as well as those of @Bas and @mperrott: add a Universal GUI config.json parameter that basically causes the Universal GUI to ignore the IAM OpenID setup.

  • Universal GUI 1: This would cause the Universal GUI app with this ignore parameter to simply show it’s own (local) Login screen: suitable for the users who require Local login
  • Universal GUI 2: The second Universal GUI app without the ignore parameter would still redirect to Indicium to show the OpenID login option (with or without the Local login button, based on the IAM setting)

@Bas @mperrott could you confirm if this would work for your scenario for the time being?

Hi @Arie V ,

This would indeed work for us, as we have as you explained above the exact same scenarios.

Thanks 
Mike


Hello @Arie V@mperrott and @Bas,

We have also started thinking about a workaround solution for this problem that we’ll be able to release relatively soon, and arrived at a similar, though slightly different solution.

As Arie wrote as well, we are thinking of introducing a config option to the Universal GUI, but instead of simply a setting to ignore OpenID, we would like developers to be able to specify the following scenarios:

Forcing local authentication

"auth_provider_hint": "local"

Forcing an OpenID provider

"auth_provider_hint": "Microsoft"

Allowing multiple of the available options, but not all of them

"auth_provider_hint": "local, Microsoft"

Not specifying the config option in the Universal GUI will lead to the default behavior; all authentication options will be available.

Specifying the config option will always cause a redirect to Indicium, however, Indicium will only allow the specified authentication options. If only one authentication option is available, it will automatically be selected. So for “local”, Indicium will automatically navigate to its local login page without first showing the overview page of the other options. For “Microsoft” (i.e. the name of your OpenID provider in IAM), Indicium will automatically redirect to the Microsoft login page. If you have local, Microsoft and Google as options, but you specify “local, Microsoft”, you will see the overview page, but the Google button will be missing.

We are trying to cover a few more bases this way, for instance the use case of allowing 2 authentication options for one Universal GUI and 3 authentication options for another Universal GUI.

Does this sound like an acceptable solution?


@Vincent Doppenberg Sounds like a more flexible and thus a better solution than I suggested: of course that’s acceptable at this stage!

Just so I’m sure there is no misalignment in expectations: this would work with using 1 IAM, 1 Indicium and multiple different Universal GUIs (1 for each setting), right?


Just so I’m sure there is no misalignment in expectations: this would work with using 1 IAM, 1 Indicium and multiple different Universal GUIs (1 for each setting), right?

Yes, exactly.


Sorry for the delay but managing this via the config.json sounds like and excellent solution for now.

I would be tremendously helped if this would be available before march 10th.


Hello @Arie V, @mperrott, @Bas,

We will release this feature in the next version on February 24th. It will require both the Universal GUI and Indicium to be updated.


OpenWorking on it!

Hi @Vincent Doppenberg ,

 

Solution seems suited for us as well. Good that we see it is already being worked on.

 

Thanks 

Mike


Working on it!Next release

This will be released in the upcoming release of Universal/Indicium - 2023.1.13.


Specifying the config option will always cause a redirect to Indicium, however, Indicium will only allow the specified authentication options.

Hi @Vincent Doppenberg I raised TCP 6355 today, requesting that the Universal GUI would not redirect to Indicium when the setting ‘localLogin’ is used as only option in the config.json. Now I just noticed the quoted sentence you wrote here earlier. Why is it necessary to always cause a redirect to Indicium?


Hello Arie,

It's not necessary, but Indicium is the one that tells the Universal GUI via a response header to redirect whenever there are authentication options configured that only Indicium can handle. This response header can occur on any request and it's not feasible to have the Universal GUI attach the new authentication provider hint parameter on every request. So Indicium doesn't know which authentication providers should be available at the moment that it instructs the Universal GUI to redirect. And the Universal GUI will apply this new parameter when it is already redirecting to Indicium, to limit the options.

So it's not feasible to implement this in Indicium, however, the Universal GUI could simply ignore Indicium's redirect instructions if only LocalLogin is available - which it can handle by itself. I haven't checked ticket 6355, but it would have to be a change request for the Universal GUI. I agree that it would make a lot of sense for it to work this way.

I hope this clarifies things.


@Vincent Doppenberg Glad to read that we agree! Will wait for the Universal team to pick up on our expectations then 😏


We resolved TCP ticket 6355S as part of the 2023.1.15.0 release, so we assume we covered this idea completely by that.


Next releaseCompleted