9:35 a.m.
Why would an application need the username? I would think the application would more
likely want the id, email and first/last name. For example:
* To store an entry in a db associated to the user the id should be used
* To display the logged in user the first/last name would be used
Thinking about this further, I really think the "reference" used on a user
should be a unique id generated by the system and not a user specified string. An example
scenario for a online image gallery where using a user specified username would cause
problems:
1. User registers with 'bob'
2. User logs in to the image gallery
3. User uploads some private images
4. The user is later deleted by an admin because the user didn't pay his fees
5. Another user now registers as 'bob'
6. If the private images from the initial user are still there, the new user will now be
able to access images not belonging to him
This makes me think that Keycloak should generate user ids, and we should make sure that
even if a user is deleted, the id wouldn't be reused.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 6 February, 2014 2:59:31 PM
Subject: Re: [keycloak-dev] User ids and usernames
On 2/6/2014 9:48 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Thursday, 6 February, 2014 2:15:41 PM
>> Subject: Re: [keycloak-dev] User ids and usernames
>>
>>
>>
>> On 2/6/2014 5:02 AM, Stian Thorgersen wrote:
>>> A user should have an id, username and email (what we have now). The id
>>> should be generated by the server and should never change for a user. The
>>> sub field in the token should use this id, not the username. Applications
>>> that wants to store information associated with a specific user should
>>> also use this id, not the username or email, as the id will never change.
>>>
>>> That means it should be possible for a user to change his/her username.
>>> Obviously a username has to be unique within a realm. We should then
>>> allow
>>> a user to login with either their username or their password. When a user
>>> is able to login with their username we can also remove the forgot
>>> username option on the login form, and only have a forgot password
>>> option.
>>>
>>> This would also help integration with social login as now we don't have
>>> to
>>> try to create a sensible username for a user on social login. Instead we
>>> create a generated id, and don't even set a username. A user can then
set
>>> the username they want through the account management (or on the update
>>> profile action page if that option is enabled).
>>>
>>> If there's no objections to this, I'd like to add these changes to
>>> alpha2.
>>
>> Ugh, this is just a nasty change. usernames will rarely, if ever,
>> change and I don't like the idea that users can change their username.
>> A principal name of "bill" is much more coherent than
>> "2341235234234-234123-234123-2341234".
>
> Doesn't matter does it? It's just an identifier, if someone wants to know
> more about the user they should retrieve the user profile.
User profile would then have to be retrieved for most apps as most apps
would want to display the username. Maybe add an additional token
extension for the username? So an additional REST invocation back to
obtain the user profile doesn't need to be done?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com