Skip to main content

I’m currently facing a challenge with customizing the login screens for a multi-tenant application hosted in Azure. The client wants each tenant to have a separate, recognizable login screen, but the app is hosted in a way that makes this more complex.

 

Current setup:

The application is hosted on Azure in a single App Service. All these applications share a single IAM instance for authentication mapped to a different alias and tenant. This IAM instance controls global settings, including logos and themes, which are applied to all tenants.

Right now, the logos are combined into a single .PNG file in IAM's global settings. We’ve also made customizations to the styles.css (e.g., button styles) within Indicium, but these customizations have to be manually backed up and re-applied every time we upgrade the Indicium instance.

 

3 logo’s next to each other. 1 .PNG file.
​​

The problem:

The client wants each tenant’s login screen to be customizable—particularly the logo and styling—so they’re distinct from one another. However, the way the current architecture is set up (one App Service, one IAM instance) seems to complicate this

  • Option 1:
    One possible solution is to use a single App Service with multiple subdomains (e.g., tenant1.app.nl, tenant2.app.nl) routed through an Application Gateway. This gives me an identifier in the domain, which could be used for customization, but I’m struggling to figure out how to tie that identifier to specific customizations. For example, can I use the subdomain or alias to inject tenant-specific changes into the custom.css file? Or would I need some additional configurations to make that work?
  • Option 2:
    Another option would be to create separate App Services for each tenant, which would allow more flexibility in customization. However, this would be cumbersome in terms of maintenance, especially when upgrading the universal GUI or Indicium across multiple environments (e.g., Test, Prod). It’s also not the most cost-effective solution since multiple App Services can add up quickly (to put it lightly).

What am I missing?
Am I overlooking a simpler solution? Could I stick with Option 1 and somehow leverage the subdomains in custom.css or another way to make tenant-specific changes without breaking the current architecture? Or do I need to go down the separate App Service route and even separate IAM instances despite the extra maintenance and cost?

I know this might be a bit convoluted, but I wanted to share my thoughts and hopefully get some guidance. If more information is needed, feel free to ask—I’m happy to provide more context even if it's via Teams!

 

 

Hello ​@rbiram,

Option 1 seems possible to me, not so much by injecting changes into custom.css based on the subdomain, but rather by routing requests for different sub domains to different CSS files. The key here is that you do not need to stick to the name custom.css as long as you fix the routing yourself. By default, every Universal GUI will request /custom.css, which works because there is a custom.css file in the root of the Universal GUI.

You could set up routing in your gateway like this:

  • If request URL = abc.domain.com/universal/custom.css then route to /universal/abc.custom.css
  • If request URL = xyz.domain.com/universal/custom.css then route to /universal/xyz.custom.css

In this example, you would need the files in the Universal folder to be named abc.custom.css and xyx.custom.css.

Does that help?

 

Hi ​@Vincent Doppenberg ,

Thanks for your response! That approach does seem like it could work. However, after giving it some more thought, I realized that the CSS changes for the login screen are actually managed in the styles.css file within the Indicium folder. The custom.css file is mostly targeting the styles for the application itself. Additionally, the logo customization is handled directly in IAM via hte Global Settings.

Given that we have a single IAM instance with three application copies for each of the tenants, I’m struggling to see how would work then.

Do you have any suggestions for adapting your idea to these constraints?

Thanks in advance!

Hello ​@rbiram,

It would actually work the exact same way for Indicium. The styles.css file is requested and delivered as static content by the web server, meaning that the URL structure matches the file structure in the wwwroot folder of Indicium.

One downside of Indicium however is that we currently do not offer a great way to apply custom CSS. This doesn't actually limit your options at all, but it does cause extra work when updating Indicium. Every new version of Indicium may have changes to the styles.css file and technically it's even possible that we have changed the IDs and class names of elements on our HTML pages. So it's important to merge your custom CSS back into the new styles.css file when updating Indicium and testing if everything works as expected. Aside from that however, my suggested solution will work as well for Indicium as it does for Universal.

We do have plans to offer better first class support of custom CSS in Indicium soon by the way. See this idea.

I hope this helps.

Hi ​@rbiram,

Did you have a chance to look at this answer yet?

Definitely had a chance to look at the answer, thanks! Currently discussing it internally with the team. I'll get back to this with some more questions, or not :) 

Reply


Terms & ConditionsCookie settings