On 08/01/16 13:05, Stian Thorgersen wrote:

It's to make it less likely that the username is already in use. We could use email for the username in those cases, but email is not always available. In the past we didn't have a way to allow the user to change the username if there was a conflict and instead the first login would just fail. With the introduction of first time social flows we could improve on this.

We could allow selecting the strategy to use. Then allow the user to change if there's a conflict. We already allow users to change email if there's a conflict so can do the same for username.

We already detect conflicts in both email and username. So user can either use different username or link the account corresponding to existing username. Also as Kamal mentioned, we already have the IdentityProviderMapper, which allows to configure how is username generated ( UsernameTemplateMapper ). We don't need any other strategy IMO as the mapper is flexible enough.

Maybe we can improve how is username generated if mapper is not used? Currently the username is generated based on algorithm like this:
1) If there is IdentityProviderMapper which sets username, it has priority
2) Otherwise if realm.isRegistrationEmailAsUsername, then email from social provider is used as username
3) Otherwise if username from Identity provider is set, we generate the keycloak username like "<IDP alias>.<IDP username>" (For example "facebook.mposolda" )
4) Otherwise if username from identity provider is null, we generate the keycloak username like "<IDP alias>.<IDP ID>" (For example "facebook.12345" )

IMO the one thing, which can be improved is removing the IDP prefix in step 3 and use just the username "mposolda" . If there is conflict, it can be easily resolved thanks to first broker login flow. I would likely keep the IDP alias in step 4 as having just username "12345" is a bit confusing IMO.