Allow the Admin API to create a user where the same localpart exists with uppercase letters

[Twi1ightSparkle]

Description

Note, I have added a space after the @ in all example Matrix IDs in this issue, this is to avoid pinging the existing @ Alice user on GitHub.

Use case

There are a handful of users who have uppercase letters in their Matrix ID from before Synapse started enforcing lowercase only. They may want to create a new Matrix account with a spec compliant all lowercase localpart. Ie. they currently have @ Alice:example.com, but want to register @ alice:example.com

Proposed solution

Adding a feature to the User creation Admin API to allow registering @ alice:example.com when @ Alice:example.com already exists.

Authentication endpoints may also need updating when implementing this as these may ignore casing currently.

Security considerations

The localpart availability checker and both client-server and Admin user creation API endpoints ignore casing today and should continue doing this by default.

• This is to avoid impersonation by allowing client-server API registrations of the lowercase version of an existing MXID with uppercase letters. It is expected that server administrators have verified the users identity before registering this new lowercase Matrix user for them.
• Also to avoid changing the behavior of existing Synapse user management portals that rely on Synapse for localpart validation.

We should add a parameter to the API something along the lines of &ignore_localpart_casing_duplicates=true. This need to be an optional parameter and default to false if not set

[Twi1ightSparkle]

For additional context, see the discussion starting here (sorry to everyone not working for Element and don't have access to this internal room)

[paride]

I'm the requestor of the username capitalization change (s/Paride/paride/) that led to opening this issue (thanks @Twi1ightSparkle). I'm subscribed to it and looking forward making my username spec compliant.

[reivilibre]

Worth noting: _find_user_id_and_pwd_hash does a case-insensitive login using LOWER on both sides. It would need changing to try the exact match first or something like that.

[callahad]

Notes from discussion today:

• If allowed, this override should be a one-way gate: you can only force creation of compliant (lowercase) MXIDs using the Admin API.
• The Matrix Spec discusses Historical User IDs stating "clients and servers MUST accept user IDs with localparts from the expanded character set", meaning we would expect servers to gracefully handle the presence of users who only differ in casing.
• We should write tests which ensure that a@example and A@example can simultaneously participate in a room without servers blowing up.
• When looking up accounts during login we should prioritize an exact case match, and then fall back to a case insensitive match.

[paride]

Or maybe the "one-way gate" could cause the deactivation of the non-compliant ID when the compliant one is registered. This would eliminate many edge cases (e.g. a@example and A@example being simultaneously in a room). The identify verification @Twi1ightSparkle mentioned in the issue description should prevent unwanted account deactivations.

[Twi1ightSparkle]

Or maybe the "one-way gate" could cause the deactivation of the non-compliant ID when the compliant one is registered.

You probably don't want this for several reasons. For example: you might wanna have both accounts for a period to migrate your rooms and encryption keys. And making sure all is well on the new account before deactivating the old one. Account deactivation is not easily reversed.

[callahad]

Not sure if we'll get to this before year's end, but we should soon. It seems like a valuable thing to have in terms of shaking out unexpected corner cases in our handling of MXIDs, and malicious / buggy / chaotic server admins could do this already, so we'll have to handle it on the network somehow.

[paride]

Hi, any news on this one? Looks like there's a similar issue in dendrite: https://github.com/matrix-org/dendrite/issues/2073.