Confusing scenario with OIDC button
-
This ultimately could be/should be a feature request I guess (and if so, apologies, please fell free to move), but I thought I would ask first since I might be overlooking something.
Consider this scenario:
- Server01 -> CloudronName01 as Branding, main functions: User directory server, LDAP/OIDC base server
- Server02 -> CloudronName02 as Branding, main functions: App server
- Server01 is set as the central user directory server to which Server02 connects itself, user base is then synchronized.
Server02 has a Cloudron managed OIDC enabled app (such as for example SterlingPDF).
In the App, thanks to the recently released Cloudron update, the OIDC button now says "login with CloudronName02"The problem in this situation is that CloudronName02 is unknown to the users, because they only know CloudronName01.
Is there any suggestion about how to proceed here?
My suggestion would be to split the "Branding Name" from the "Cloudron Name" (e.g. have 2 separate fields on the Branding page) and make sure that Branding Name is applied to the OIDC button rather than the Cloudron Name
In turn, the dashboard could present Branding Name + Cloudron Name on the top of the page.
Branding Name and Cloudron Name could be each or both left empty depending on the need / situation (same as it currently is with Cloudron Name).Ultimately, the Branding Name could then be synchronized, if needs be, if/when the Cloudron multihost feature materialized.
Whatever is currently in place or alternatives (such as the above) would go a fair way in preventing end user confusions / frustrations.
-
This ultimately could be/should be a feature request I guess (and if so, apologies, please fell free to move), but I thought I would ask first since I might be overlooking something.
Consider this scenario:
- Server01 -> CloudronName01 as Branding, main functions: User directory server, LDAP/OIDC base server
- Server02 -> CloudronName02 as Branding, main functions: App server
- Server01 is set as the central user directory server to which Server02 connects itself, user base is then synchronized.
Server02 has a Cloudron managed OIDC enabled app (such as for example SterlingPDF).
In the App, thanks to the recently released Cloudron update, the OIDC button now says "login with CloudronName02"The problem in this situation is that CloudronName02 is unknown to the users, because they only know CloudronName01.
Is there any suggestion about how to proceed here?
My suggestion would be to split the "Branding Name" from the "Cloudron Name" (e.g. have 2 separate fields on the Branding page) and make sure that Branding Name is applied to the OIDC button rather than the Cloudron Name
In turn, the dashboard could present Branding Name + Cloudron Name on the top of the page.
Branding Name and Cloudron Name could be each or both left empty depending on the need / situation (same as it currently is with Cloudron Name).Ultimately, the Branding Name could then be synchronized, if needs be, if/when the Cloudron multihost feature materialized.
Whatever is currently in place or alternatives (such as the above) would go a fair way in preventing end user confusions / frustrations.
@Neiluj said in Confusing scenario with OIDC button:
The problem in this situation is that CloudronName02 is unknown to the users, because they only know CloudronName01.
Is there any suggestion about how to proceed here?
Is there any reason why, for now, you couldn't just change the name of CloudronName02 to match CloudronName01?
-
Good points and indeed a longstanding issue. Besides the actual branding (cloudron name and logo) another issue is the domain where the login form is delivered. Currently, the user would see the origin from the Cloudron where the particular app is installed. This also means it may not be autofilled by a passwordmanager.
From a technical perspective, since we mostly came from LDAP, internally the cloudron to cloudron user directory syncing is still facilitated with a custom LDAP schema. Since we have moved mainly to OpenID, we can hopefully fix this properly in the future.
Ideally the Cloudron acting as the user directory, should become the OpenID provider for the other Cloudrons (in your example Cloudron 02). That way the user would be redirected to the origin of the user known Cloudron01, autofill and also autofil for 2fa would just work if the user had set that up.
I hope we can get this done in the next few Cloudron versions.
-
@Neiluj said in Confusing scenario with OIDC button:
The problem in this situation is that CloudronName02 is unknown to the users, because they only know CloudronName01.
Is there any suggestion about how to proceed here?
Is there any reason why, for now, you couldn't just change the name of CloudronName02 to match CloudronName01?
-
@Neiluj said in Confusing scenario with OIDC button:
The problem in this situation is that CloudronName02 is unknown to the users, because they only know CloudronName01.
Is there any suggestion about how to proceed here?
Is there any reason why, for now, you couldn't just change the name of CloudronName02 to match CloudronName01?
@jdaviescoates said in Confusing scenario with OIDC button:
Is there any reason why, for now, you couldn't just change the name of CloudronName02 to match CloudronName01?
@jdaviescoates This is indeed the alternative that one might use for now.
However it gets confusing pretty quickly in the setup and administering of the Cloudron servers, the users and applications
-
Good points and indeed a longstanding issue. Besides the actual branding (cloudron name and logo) another issue is the domain where the login form is delivered. Currently, the user would see the origin from the Cloudron where the particular app is installed. This also means it may not be autofilled by a passwordmanager.
From a technical perspective, since we mostly came from LDAP, internally the cloudron to cloudron user directory syncing is still facilitated with a custom LDAP schema. Since we have moved mainly to OpenID, we can hopefully fix this properly in the future.
Ideally the Cloudron acting as the user directory, should become the OpenID provider for the other Cloudrons (in your example Cloudron 02). That way the user would be redirected to the origin of the user known Cloudron01, autofill and also autofil for 2fa would just work if the user had set that up.
I hope we can get this done in the next few Cloudron versions.
@nebulon All of this (URL, password manager etc..) as well as the origin of the situation (LDAP roots) make sense and would be indeed much appreciated because this is something that I faced a few times already.
So here
is to hoping this get implemented sometime soon.Many thanks,
-
N Neiluj referenced this topic on
-
+1
It would be really great if we could have a second configuration field in the "Branding" tab that can explicitly set the value of the
CLOUDRON_OIDC_PROVIDER_NAMEwith a fallback to the Cloudron name. Setting the same Cloudron name for all instances that connect to an LDAP just isn't a feasible solution in my opinion and makes administration chaotic. Non-Technical Users could also really benefit from a name like "Login with One-Click" - and naming the whole instanceOne-Clickjust feels like a bad idea.
