Skip to main content
Solved

Azure App Service and Sub-domain per application - With O365 and without on 2022.2 version

  • September 7, 2022
  • 4 replies
  • 217 views
mperrott
Hero
Forum|alt.badge.img+12

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’. 

Best answer by Anne Buit

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.

View original
Did this topic help you find an answer to your question?
This topic has been closed for comments

Anne Buit
Community Manager
Forum|alt.badge.img+5
  • Anne Buit
  • Community Manager
  • September 13, 2022

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.

mperrott
Hero
Forum|alt.badge.img+12
  • mperrottHero
  • Hero
  • September 13, 2022

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
1 person likes this
  • Anne Buit
    Anne Buit
Arie V
Community Manager
Forum|alt.badge.img+12
  • Arie V
  • Community Manager
  • September 14, 2022

@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

mperrott
1 person likes this
  • mperrott
    mperrott
Arie V
Community Manager
Forum|alt.badge.img+12
  • Arie V
  • Community Manager
  • November 16, 2022

Idea raised for a better solution: 

https://community.thinkwisesoftware.com/ideas/custom-login-screens-with-different-default-login-settings-3340

 

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings