Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a registered user, I want to rename my username for various reasons #105

Open
Conan-Kudo opened this issue Feb 6, 2020 · 21 comments
Open
Labels

Comments

@Conan-Kudo
Copy link
Contributor

Conan-Kudo commented Feb 6, 2020

There are a number of sociopolitical or legal reasons for needing to being able to rename usernames.

A couple of examples:

  • Change in marriage status
  • Gender transition

Whether Fedora itself allows it or not right now is a separate question, but it would be very bad if it's never possible to rename usernames.

@Conan-Kudo Conan-Kudo changed the title As a registered user, I want to be able to rename my username for various reasons As a registered user, I want to rename my username for various reasons Feb 6, 2020
@abompard
Copy link
Member

abompard commented Feb 6, 2020

This is probably not going to be in the scope of securitas (the self-service portal), but I'm interested in knowing whether IPA can do it. If it can and we allow it (which is indeed a different story), this could go through an infra ticket.

@Conan-Kudo
Copy link
Contributor Author

What would impair it being supported as a self-service feature?

@Conan-Kudo
Copy link
Contributor Author

@abompard I don't know of a technical reason IPA couldn't do it, since the key is the UID and not the username.

@abompard
Copy link
Member

Actually, user entries in IPA's LDAP directory are keyed on username, this is what an ldapsearch gives me: dn: uid=abompard,cn=users,cn=accounts,dc=example,dc=com

It's possible in LDAP to rename an entry, but I don't know if IPA has an API for that.

@Conan-Kudo
Copy link
Contributor Author

Hmm, do we maintain some kind of uid number mapping?

@tiran
Copy link

tiran commented Feb 18, 2020

IPA supports renaming of users:

# ipa user-add janedoe --first Jane --last Doe
--------------------
Added user "janedoe"
--------------------
  User login: janedoe
  First name: Jane
  Last name: Doe
  ...
# ipa user-mod janedoe --rename janesmith --last Smith
-----------------------
Modified user "janedoe"
-----------------------
  User login: janesmith
  First name: Jane
  Last name: Smith
  ...

This will rename the login uid. 389-ds also updates all relations that are tracked by referential integrity plugin.

# ipa user-show janesmith --all
  dn: uid=janesmith,cn=users,cn=accounts,dc=ipa,dc=example
  ...
# ipa group-show --all --raw ipausers | grep member
  member: uid=janesmith,cn=users,cn=accounts,dc=ipa,dc=example

@abompard
Copy link
Member

Very cool, thanks @tiran !

@tiran
Copy link

tiran commented Feb 18, 2020

ipa user-mod --rename also renames the UPG (user private group) and tracks the former name as Kerberos principal alias:

  ...
  Principal name: [email protected]
  Principal alias: [email protected], [email protected]
  ...
  mepmanagedentry: cn=janesmith,cn=groups,cn=accounts,dc=ipa,dc=example

@ryanlerch
Copy link
Contributor

Okay, so the question on this one is that is this something that we want to allow users to change self-service?

I'm leaning towards not being self-service.

@Conan-Kudo
Copy link
Contributor Author

@ryanlerch Is there a good reason for this to not be self-service? So far, nobody has made a decent rationale for it not to be.

@tiran
Copy link

tiran commented Mar 26, 2020

Rename requires administrative privileges for a reason. For one rename does not free the old user name. The old user name will stay an alias. If you allow arbitrary renames, then one user can claim an unlimited amount of user aliases.

You cannot remove the aliases safely either.

@mscherer
Copy link

If the problem is the risk of having a unlimited amount of user aliases, then just do not make it unlimited. For example, if you let people do 1 rename per year (assuming people do not change name on average more than that), then it can be self service without any abuse that would result into having a unlimited amount of alias.

@abompard
Copy link
Member

To do that we would need to store the time of last change somewhere. Does FreeIPA store it?

@tiran
Copy link

tiran commented Apr 15, 2020

389-DS maintains the modifyTimestamp operational attribute. The attribute is updated every time any attribute is changed. There is no dedicated field that tracks last rename TS.

I suggest that you check the krbprincipalname attribute and prohibit self-rename if the attribute contains more than two or three entries. This should cover the majority of use cases.

@abompard
Copy link
Member

Thanks for the tip Christian. Here's how we could do it:

  • add a configuration option MAX_USER_RENAMES set by default to, say, 5
  • in a user's settings page, add a link to a rename page
  • that page would look at the current number of kerberos aliases in krbprincipalname, display the number of allowed renames for that account and ask for the new username
  • on POST, it would call user_mod with the rename parameter set to the new username.
  • ideally it would update the current session, but if that's impossible the user would have to login again with the new username.

Does it sound sane?

@mscherer
Copy link

5 seems enough, but what happen if someone do more than that ? I did a search on wikidata, and for example Elizabeth Taylor was married 7 times, Pamela Anderson was married 4 or 5 times, just to give a few examples of women (cause there is a lot of men who got married more than 5 times, but they do not change their name). While that's unlikely (I found just a dozen of case), but that's also not impossible. I can also imagine people doing that for testing, so maybe we should also direct folks on staging for testing/demo.

I bring the testing issue, since once the information is changed on noggin, then there is the question on what happen on other systems.

For example, if I rename myself from misc to miscthegreat, would pagure be updated (and add "symlink/aliases", would badges be transfered ?

I suspect the answer is "no", so I guess once that's done for noggin, we need to start thinking of "the rest of the world", and that's where having a process on stg would help, as I guess we might losen restriction there (or handle it differently).

For example, do we want people to be able to rename the username in stg, and not in prod, etc.

Another question I do have, should people be able to revert back to the old username ?
If I get married, then get divorced, can i get back the old username ?

@tiran
Copy link

tiran commented Apr 15, 2020

IPA will keep the old user names as Kerberos principal names. You'll be able to get back to your old name because it's still reserved for you.

An admin can remove any additional names. I recommend to keep the additional names until you are sure that all session aligned to old names are invalid.

By the way IPA creates ipaUniqueID for most entities (users, groups, services, hosts, ...) and the uidnumber typically do not change or get reused. External systems could either use the numeric uid or UUID to track users.

@jwflory
Copy link
Member

jwflory commented Apr 2, 2021

Hi all. Now that Noggin is deployed to production, is there an opportunity to revisit this? Or is it already possible to do in production?

@stewartadam
Copy link

+1 would also like to rename my Fedora account, is this now possible? Couldn't find anything in the UI.

@ByteHackr
Copy link

Hey @abompard, any Updates regarding this?

@Mikaela
Copy link

Mikaela commented May 9, 2022

I recently logged in to fedora.im which brought my username predating gender transition mkaysi. I am not that bothered by it 9 years after and it's ambiguous enough, but I wonder how would changing FAS username affect Matrix as a federated system?

Room (including "direct chat") membership is tied to the Matrix ID containing the username, and if the MXID left all rooms, there would still be question of transferring power(level) in rooms which a single server cannot change as the other servers would see that change as invalid (especially if the MXID wasn't currently in the room or not permitted to change m.room.power_levels).

Would that mean this is blocked by matrix-org/synapse#12174 or decoupling MXIDs from servers (matrix-org/matrix-spec#246)?

@ryanlerch ryanlerch added the todo label Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants