Hey Nick, I definitely dont want to sound the alarm bells on this because as all your points are indeed very valid, the trust starts at the Idp. But let me perhaps mention a real world scenario and why this came up.
Microsoft Entra is currently employed as the IdP. It has this concept called B2B trust which essentially allows you to open your application to external Microsoft Entra tenants which you trust. This is itself is very useful as you don’t need to manage all these users yourself on your home tenant as long as they meet some continuous approval process. But now you must guarantee that that these claims remain static of these external IdPs after validation and this is very hard to do as even the helpdesk administrator role can change the display names or emails of regular users. So after someone was granted access to the application their displayname or email could be modified but their access remains valid as for the IdP its still the same user with the same application assignment but now on the guac side you might have a local db user that has admin privileges called “admin” (I know bad name to use) which will map this new displayname to this admin user that perhaps has high privileges. So prevent such scenario our only option was to use an immutable claim such as the object id but the downside is that we had to sacrifice human readability in guac. From: Nick Couchman<mailto:[email protected]> Sent: maandag 9 oktober 2023 16:26 To: [email protected]<mailto:[email protected]> Subject: Re: Separating username from display name On Mon, Oct 9, 2023 at 9:59 AM Najib . <[email protected]<mailto:[email protected]>> wrote: Hi Nick, The change depends on the current implementation of usage of the username across the front end. A Simple implementation would check in the frontend if a user has a Fullname/displayname and use that and only doing a fallback to the username if the former is empty. Another possible implantation is to let admins decide which value to use as the display name in the front end such as username, fullname or even email which are already part of a guac user profile. Yep, understood, and this is doable - I was just highlighting that it isn't something that can be easily reconfigured as it is implemented, there are code changes that need to be made. It isn't terribly difficult, just requires some level of effort to do. This would make envinrments using the OIDC extension more secure as well. Because many would just go for the most straight forward claim such as the email or display name on the IDP. But this can be easily abused if you can change these values to impersonate someone with higher privileges. For instance Microsoft recommends using the object id claim which is an immutable GUID and unique across their entire cloud. But doing so in Guac makes it challenging for admins to link these values to actual users without doing some dig work. I'm not sure I fully agree with you, here: 1) The display name has nothing to do with security, it's a usability thing. 2) While I see what you're saying - and generally agree - about the security of using a GUID rather than username or e-mail to track accounts between different systems, I'm not sure I'd agree that this can be "easily abused." Doing so would require access to either modify the data that the IdP is sending back to Guacamole, or, at the very least, intercept and alter the data (MITM) between the IdP and Guacamole. Having access to do either of these things un-checked implies either intentional malicious activity by a privileged user (administrator) of the IdP, a lack of proper trust configuration between the IdP and Guacamole, or that you've given your users (non-administrators) too many privileges with respect to the IdP. All three of these are pretty serious issues that have implications outside of just the IdP <-> Guacamole relationship, and none of these should be easy to do. If you don't trust your IdP Admins to do the right thing, you probably shouldn't be authenticating your Guacamole instance - or anything else for that matter - against that IdP. That's not to say I'm opposed to changes that would either change the display value used, or use some other mechanism to track user identification within Guacamole. I just don't think we need to be terribly alarmist about the current implementation. -Nick
