How to set preferred_username?

[flohoss]

After looking in docs and checking with the API I am going to ask the question here? How can I set the preferred_username to something other than the email?

I was successful in sending it as an attribute, but normal oidc clients do not accept attributes as a claim.

Am I just not seeing the setting?

Thanks for the great software!

[sebadob]

Currently, you can't.

I thought a few times about it already, if / how to allow this, but I haven't found a nice solution yet.

The problem is, that if I would just allow to set this in the username dashboard for instance, I could either:

• make it some generic input field, just a simple string without any further validation for it (like being unique e.g.)
• check that it is a unique username (at least for Rauthy)

If it would be just an abitraty string without uniqueness checks and your downstream app uses this claim, then this will lead to more and more conflicts the more users you have.
If I check for uniqueness on the other hand, Rauthy would deny usernames for certain users, that maybe belong to them, but Rauthy can't validate, because they are external. Let's say I have a user and use a Matrix handle from someone else for instance as my preferred_username and the downstream app actually uses this claim and thinks this is valid and checked, this could lead to even more trouble.

If you have an idea about this, I would be happy to hear about it. Currently, I just don't think that this is a claim any downstream client should use and it is there more or less for completeness. The email inside this field is the only value that Rauthy can actually validate and make sure, that any downstream client can trust this value and just use it.

[flohoss]

Kanidm allows for a username but for example is using a SPN as preferred_username (username@sso.domain.com) unless you explicitly tell it to use a short username with this command:

Use the 'name' attribute instead of 'spn' for the preferred_username: kanidm system oauth2 prefer-short-username

Use the 'spn' attribute instead of 'name' for the preferred_username: kanidm system oauth2 prefer-spn-username

If you use an SPA with email, it would give the user by default a secure and unique preferred_username unless they activate a non-unique username so it should be used in combination with the email in the service that uses it.

I started seeing this as a problem when using Memos. When using Rauthy, it created a new account...

Most of the software i use is fine using email as only claim necessary and the User sets everything else directly in the app.

[sebadob]

Got it, yes. So your flohoss user existed before and then you did the SSO login? It is actually a good idea to not just link and existing user after an SSO login blindly, because this could lead to account takeover if the implementation is not really careful about it.

The problem (if you want to call it like that) in that case is not Rauthy but Memos actually, if it does not allow for OIDC claim mapping like any other application or does not take the E-Mail into account, or at least provide an option. Even in this scenario, any user could simply enter flohoss as their username and would be linked to your account on Memos I guess. An E-Mail is a unique identifier globally, because its only you who can own this address, a preferred_username can be anything a user wishes.

If, what, how and when to link existing accounts automatically after an upstream login is actually a design question in the end. Rauthy for instance does not allow this for existing accounts for security reasons. The upstream linking is an action you need to initiate on purpose from an already authenticated and logged in session to prevent account takeovers from a bad upstream provider.

I could allow any user to set their own username, but this would lead to way more confusion than it would solve problems I think. I just don't know any good solution for this. I mean, I could just add a config option that strips off the domain for a "nicer looking username", but then we end up with non-unique usernames all over the place again without any benefit and its just a super bad idea for any downstream app to use this claim as any sort of ID in the first place.

If I would add an input field for users to specify it, I would need to make it opt-in most probably, which means its not so quickly done, because it needs additional checks between frontend and backend. Mapping from a completely unvalidated claim to a user is a big problem and as it is now, downstream apps which mess this up cannot do this on accident at least.

I am not against doing anything about it, I just don't see a really good solution for this.

This is straight from the OIDC RFC:

The RP MUST NOT rely upon this value being unique (...)

I think the must not is pretty clear, so I could make it a trivial "any input value you wish" field and add it with an update. Then it's the downstream app's issue. ^^

[flohoss]

Got you. I just recently started to look at Keycloak, Authentik, Logto and Authelia. So far i love how easy Rauthy is to setup and get running. No fuss, no extras, just what i need. Also the GUI is a game changer compared to Kanidm. Thanks again for your work!

[sebadob]

Thanks! That was the goal with this project.

I am thinking about adding an input field for this with the next release, I am just not sure about it yet. Maybe I can even find a nice solution for this.

Thanks for the issue. Such things always help making it better and get a new perspective.