@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?

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?

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.

Hi @Vincent Doppenberg ,

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

Thanks 

Mike

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

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.

Updated the status of this Idea to ‘Partially completed’, as we still owe our Customers a more robust solution. Inspiration: https://trailhead.salesforce.com/content/learn/modules/identity_login/identity_login_my_domain

​@rbiram FYI, the robust solution should also cater for the scenario you’re trying to resolve here: Customizing Login Screen Styling for Multiple Tenants | Thinkwise Community

@Community: are there existing Customers / Use Cases for which this is important too? Please let me know, as I’d like to do proper Discovery sessions before building the solution!

To add to this, could be included here the default title ‘Universal’.. to most users this doesn't say anything and to my knowledge there is not way now to give the GUI pre-login another name. That said, we have a customer that has 1 IAM and 3 GUI's, one for the administrator (IAM), one for production and one for acceptance. It would be great indeed to steer more the title, icons et cetera pre-login.. or maybe it's even possible to have them colors available pre-login based on the default application that is filled in in the settings.json. 

An update on this topic. Approximately one week ago, we held a meeting to discuss this topic with ​@rbiram and Arie. We also included the questions from this community topic in this meeting:

Customizing Login Screen Styling for Multiple Tenants | Thinkwise Community

We are exploring a solution that enables different styling options based on the domain name, configurable for each tenant. This would include elements such as:

- Custom background images, logo, and browser icon (favicons).
- Color themes, maybe implemented through custom CSS tailored to the domain/tenant.

There are still a few things to investigate, including where this functionality will be implemented, Universal or Indicium. At this moment the login experience is different in certain scenarios, and we need to provide a good experience in all of them.

 - With local accounts, users only see the Universal login page.
 - Local accounts with TOTP also go through the Indicium pages.
 - When OpenID is used, the Universal GUI redirects to the Indicium Login page.
 - What if they don't use Universal at all.

The solution we choose needs be secure and should provide a good user experience in all scenarios.

We aim to address these questions soon and are targeting a Q4 2025 release for this feature.
 

​@Dick van den Brink, does this also cover a situation where I want a different login for administrators that use local accounts vs the regular users (on the same tennant) that log in via their MS Entra account?

I don’t want to bother the main population with having to select a login option and use an easy to remember link, ie myapp.customer.com where I’d like admins to be able to log in via myapp.customer.com/admin.

edit: and no, i don’t want to use two seperate GUI’s to serve out two login endpoints.

Hi Robert Jan,

Would a specific domain for admins, that uses the global settings work for this scenario? It would mean there won't be a filter for the login options in this scenario.

For the tenant - myapp.customer.com it would use tenant specific settings (with filter on types of logins).

I will think about this some more. We don't know exactly yet where the login page will be implemented, but the starting point will be Universal. There has to be something unique - so I hope multiple domains are not a problem.
I agree that two separate GUI's is not a desired solution.

A specific domain would not be my preferred option, for example it can cause issues around certificates. Best option would be a specific endpoint. A lot of customers have a specific domain they use for a lot of things:

www.company-name.com for their website

mail.company-name.com for their outlook web access

my-thinkwise-app.company-name.com for their Thinkwise application.

So I think the admin login (or login with all options) should be something like my-thinkwise-app.company-name.com/admin