[GH-ISSUE #592] Display Name not required to be unique.

kerem commented

2026-02-27 08:15:55 +03:00

Owner

Originally created by @tetricky on GitHub (May 25, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/592

I am having an issue where the "Display Name:" can be set to the same "Display Name:" as another account with different "User ID:"

This allows for the possibility to allow a user to change their display name and spoof another user in applications that use "displayname" to identify the user in the application.

I would prefer if this field had to be unique, like username and email address...but appreciate this might possibly be a problem for others usage.

My workaround with this, is to deny users access to their lldap user login...but the preference would be to test for the displayname to be unique.

Originally created by @tetricky on GitHub (May 25, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/592 I am having an issue where the "Display Name:" can be set to the same "Display Name:" as another account with different "User ID:" This allows for the possibility to allow a user to change their display name and spoof another user in applications that use "displayname" to identify the user in the application. I would prefer if this field had to be unique, like username and email address...but appreciate this might possibly be a problem for others usage. My workaround with this, is to deny users access to their lldap user login...but the preference would be to test for the displayname to be unique.

kerem closed this issue

2026-02-27 08:15:56 +03:00

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@nitnelave commented on GitHub (May 25, 2023):

Hmmm... What applications use the display name to identify users? It feels wrong, they should use the uid (alternatively cn).

@nitnelave commented on GitHub (May 25, 2023): Hmmm... What applications use the display name to identify users? It feels wrong, they should use the uid (alternatively cn).

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@tetricky commented on GitHub (May 25, 2023):

It's forum software, specifically misago.

If I can explain the use case. A user logs in to authelia (using their username, and their email, which are unique). Misago accepts the authentication and maps their displayname as their username within misago. So that people are referred to by their preferred name, and shouts and invitations are to this (their displayed name). Their authentication username and email remains unknown to other users (for good reason).

Displayname is important in this regard because it is the name by which people choose to be referred to and can contain capitalisation and spaces, unlike username.

In this scenario if a user can change their displayname to that of another user mayhem ensues.

@tetricky commented on GitHub (May 25, 2023): It's forum software, specifically [misago](https://misago-project.org/). If I can explain the use case. A user logs in to authelia (using their username, and their email, which are unique). Misago accepts the authentication and maps their displayname as their username within misago. So that people are referred to by their preferred name, and shouts and invitations are to this (their displayed name). Their authentication username and email remains unknown to other users (for good reason). Displayname is important in this regard because it is the name by which people choose to be referred to and can contain capitalisation and spaces, unlike username. In this scenario if a user can change their displayname to that of another user mayhem ensues.

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@dougmaitelli commented on GitHub (May 26, 2023):

Sorry for stepping in without being called, but @nitnelave is right.
No application should use display name to identify a user and the possibility of having multiple users with the same name is not a bug.
I believe that usually in a LDAP scenario you would be responsible to manage the user directory as an admin and not just let users change their display name as they wish, this way you can enforce unique name yourself if you want, but this is not something that LDAP should do.

Also, I could not find any examples on misago documentation about configuring LDAP, just OAuth. How did you configure your scenario? Are you using LLDAP in a reverse proxy and using the reverse proxy to authenticate misago?

@dougmaitelli commented on GitHub (May 26, 2023): Sorry for stepping in without being called, but @nitnelave is right. No application should use display name to identify a user and the possibility of having multiple users with the same name is not a bug. I believe that usually in a LDAP scenario you would be responsible to manage the user directory as an admin and not just let users change their display name as they wish, this way you can enforce unique name yourself if you want, but this is not something that LDAP should do. Also, I could not find any examples on misago documentation about configuring LDAP, just OAuth. How did you configure your scenario? Are you using LLDAP in a reverse proxy and using the reverse proxy to authenticate misago?

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@tetricky commented on GitHub (May 26, 2023):

Totally accept your points.

I'm using authelia as an oauth provider, with an ldap backend. The forum software delegates authentication and identity to that. Within the software I believe it uses email as the source of identity....and takes the users displayname as the username. Which is what causes a potential problem in my scenario.

Where the identity pool is sufficiently small that there is no natural displayname duplication (and users are not mischievous and want to be confused with other users), there is no issue. Expand beyond that, and there is a potential issue. Not just in allowing users to change their displayname, but in admins checking a displayname request against existing displaynames. Not a problem for tens, or even hundreds of users...but starting to become onerous for thousands, or facebook levels of users.

Now I accept that is not likely to be the case in small identity/authentication scenarios...and I'm certainly not saying that it is a bug. I am, hopefully respectfully, initiating a discussion because there are circumstances where it might be a factor due consideration.

If you consider, say, the acting profession - where 'users' are restricted to a 'professional name' that does not clash with other users. Is there not a case in an identity and auth scenario where duplicate displaynames can be restricted to avoid confusion?

As I say, I recognise the functionality is as intended...and I acknowledge the workaround for my potential issue as being an admin function....and equally I recognise that it's all moot if applications use the username (or email) as the single source of truth and display the username and not the displayname.......but to a degree, why bother having a displayname at all then (except that it's used, and thus required by many applications).

If identity is delegated, where could checks on duplication in this area be moderated, except in the ldap backend?

@tetricky commented on GitHub (May 26, 2023): Totally accept your points. I'm using authelia as an oauth provider, with an ldap backend. The forum software delegates authentication and identity to that. Within the software I believe it uses email as the source of identity....and takes the users displayname as the username. Which is what causes a potential problem in my scenario. Where the identity pool is sufficiently small that there is no natural displayname duplication (and users are not mischievous and want to be confused with other users), there is no issue. Expand beyond that, and there is a potential issue. Not just in allowing users to change their displayname, but in admins checking a displayname request against existing displaynames. Not a problem for tens, or even hundreds of users...but starting to become onerous for thousands, or facebook levels of users. Now I accept that is not likely to be the case in small identity/authentication scenarios...and I'm certainly not saying that it is a bug. I am, hopefully respectfully, initiating a discussion because there are circumstances where it might be a factor due consideration. If you consider, say, the acting profession - where 'users' are restricted to a 'professional name' that does not clash with other users. Is there not a case in an identity and auth scenario where duplicate displaynames can be restricted to avoid confusion? As I say, I recognise the functionality is as intended...and I acknowledge the workaround for my potential issue as being an admin function....and equally I recognise that it's all moot if applications use the username (or email) as the single source of truth and display the username and not the displayname.......but to a degree, why bother having a displayname at all then (except that it's used, and thus required by many applications). If identity is delegated, where could checks on duplication in this area be moderated, except in the ldap backend?

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@tetricky commented on GitHub (May 26, 2023):

P.S. The misago software does test for collision detection on displayname, and append a suffix to denote that it is a unique user.

In this specific case, that resolves that as an issue for me. I am interested in opinion on the wider case...and quite happy to accept that it's not an issue, and not the responsibility of ldap....and indeed it might be a beneficial feature, because some people like to be called the same thing.

@tetricky commented on GitHub (May 26, 2023): P.S. The misago software does test for collision detection on displayname, and append a suffix to denote that it is a unique user. In this specific case, that resolves that as an issue for me. I am interested in opinion on the wider case...and quite happy to accept that it's not an issue, and not the responsibility of ldap....and indeed it might be a beneficial feature, because some people like to be called the same thing.

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@martadinata666 commented on GitHub (May 26, 2023):

Display Name intended to be freely changed like how people had the same name everywhere.
Application defines a single source of truth by UID/usernames or email.
You should try setup Nextcloud, it properly uses Display Name. That is mostly limitation in the application itself that can't use display name properly or even use display name. Usually, it just use username/UID.
P.S. The misago software does test for collision detection on displayname, and append a suffix to denote that it is a unique user. this itself already indicated username/uid as it need to be unique and become UID/username itself.

@martadinata666 commented on GitHub (May 26, 2023): 1. Display Name intended to be freely changed like how people had the same name everywhere. 2. Application defines a single source of truth by UID/usernames or email. 3. You should try setup Nextcloud, it properly uses `Display Name`. That is mostly limitation in the application itself that can't use `display name` properly or even use `display name`. Usually, it just use `username/UID`. 4. `P.S. The misago software does test for collision detection on displayname, and append a suffix to denote that it is a unique user.` this itself already indicated username/uid as it need to be unique and become UID/username itself.

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@dougmaitelli commented on GitHub (May 26, 2023):

@tetricky, I believe this is configurable in Authelia, isn't it? So you should be able to tell Authelia to use the user id from LDAP instead of the display name

@dougmaitelli commented on GitHub (May 26, 2023): @tetricky, I believe this is configurable in Authelia, isn't it? So you should be able to tell Authelia to use the user id from LDAP instead of the display name

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@dougmaitelli commented on GitHub (May 26, 2023):

This is how I have my Authelia setup and I don't have that issue:

@dougmaitelli commented on GitHub (May 26, 2023): This is how I have my Authelia setup and I don't have that issue: ![image](https://github.com/lldap/lldap/assets/1277391/4d6be827-8789-4ed8-8eb0-a5f718906393)

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@tetricky commented on GitHub (May 26, 2023):

I totally accept that is a way around it. But....the username is immutable. It's what someone selected when they registered with the system to use as a login, way back in the dim reaches of distant time, within the constraints of a valid username. displayname, on the other hand, might be how they would prefer to be seen, and addressed, as today.

@tetricky commented on GitHub (May 26, 2023): I totally accept that is a way around it. But....the username is immutable. It's what someone selected when they registered with the system to use as a login, way back in the dim reaches of distant time, within the constraints of a valid username. displayname, on the other hand, might be how they would prefer to be seen, and addressed, as today.

kerem commented

2026-02-27 08:15:56 +03:00

Author

Owner

@tetricky commented on GitHub (May 28, 2023):

I take onboard the view that displayname can, and should be able to be, whatever. Even a duplicate. ....and the responsibility is with the app delegating authentication and identity to deal with that.

I appreciate the contribution and discussion to inform this issue for me.

I'm marking this as closed, as there is clearly nothing for lldap to do here.

@tetricky commented on GitHub (May 28, 2023): I take onboard the view that displayname can, and should be able to be, whatever. Even a duplicate. ....and the responsibility is with the app delegating authentication and identity to deal with that. I appreciate the contribution and discussion to inform this issue for me. I'm marking this as closed, as there is clearly nothing for lldap to do here.

kerem referenced this issue

2026-02-27 08:18:14 +03:00

[PR #219] [MERGED] Fix handling of users with no groups #625

Rows
Columns

[GH-ISSUE #592] Display Name not required to be unique. #219