I have currently in our live production System 3 separate applications for which:
- The 2 Applications share the same DB but separate GUI and subdomain access
- Universal GUI+Indicium on App Service A
- Web GUI on App Service B
- The 3rd Application separate DB and subdomain access
- 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.
- 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’.
Best answer by Anne BuitView original
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.
@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.
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:
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: