On Mon, Oct 9, 2023 at 9:59 AM Najib . <[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 >
