Skip to main content

Hi all,

I have currently in our live production System 3 separate applications for which:

  1. The 2 Applications share the same DB but separate GUI and subdomain access
    1. Universal GUI+Indicium on App Service A
    2. Web GUI on App Service B
  2. The 3rd Application separate DB  and subdomain access
    1. Universal GUI+Indicium on App Service C

The reason we have separate App Service was to enable O365 login on App Service C, as the users of App Service A, B cannot be enabled yet. The subdomain is for creating individual uniqueness of the published app to differenciate to users.

App Service A Universal GUI login:

App Service B Web GUI login:

App service C Universal GUI Login with O365 only:

 

NOW with the 2022.2 version and the new openID Provider being configured in the IAM, there is no possibility to have the App Service A login but Only App Service C.

Questions:

  • How or what can I configure to have the same specific logins as it was before?
  • Is this a matter of IAM and openID Provider cannot be assigned to specific Published APP in IAM?

Comments on the OpenID provider:

If in the future I have separate O365 with ‘Microsoft’ name and ID, I cannot use a second one as the name is already taken and the App registration breaks if I use ‘Microsoft 1’ as the return urls are towards specific subdomain and only ‘Microsoft’. 

This has indeed changed due to the centralization of OIDC information in IAM. The exact same set-up as with 2022.2 and earlier using local configuration in Indicium is no longer possible. The OIDC information has to be available in IAM for OIDC user provisioning.

The only way to currently achieve your desired scenario is by creating a separate IAM database for App Service C. The docs also mention this in the tenancy considerations overview. Customer-specific SSO requires a multi-instance environment.

I’m not quite sure I understand the comment regarding the name being taken. The return URL is generated by Indicium based on the configuration in IAM and should not be limited by O365. More info here.

Thank you @Anne Buit for the reply,

Seems we will need to copy the IAM and create a separate instance for the application to have the SSO  with O365 and once all Applications are migrated to Universal GUI we merge IAMs back together.

You can ignore my last comment.

@Anne Buit I strongly believe you should provide a better solution for this use case. Was brainstorming a bit with @Vincent Doppenberg and @Dick van den Brink yesterday, and I think it would serve your clients better to provide ways to have multiple login screens/endpoints for different use cases. Adding additional IAM databases is not something I would be happy with.

Let me give 2 examples:

1. Same as for @mperrott, as a ‘regular’ client we most likely will end up with the following login use cases:

  • SSO with Azure AD (tenant-specific) for our office staff, I want to have them automatically redirected to the Microsoft login page and ensure our tenant-based security levels (MFA / Conditional Access policies)
  • IAM login for our Crew on board, they might not have a company email / O365 license
  • SSO with Microsoft (common) / Google for external partners

2. For ISVs who want to host a multi-tenant environment, but also wish to allow their clients to choose specific login options. 
 

See for inspiration how Salesforce provides a ‘My domain’ option to setup SSO and (optionally) override the generic login.salesforce.com endpoint: https://trailhead.salesforce.com/content/learn/modules/identity_login/identity_login_my_domain

Idea raised for a better solution: 

 

Terms & ConditionsCookie settings