[keycloak-dev] Why the provider prefix in username?

[Marek Posolda]

On 12/01/16 08:57, Stian Thorgersen wrote:
>
>
> On 11 January 2016 at 22:34, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     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.
>
>     WDYT?
>
>
> I didn't know that. Is the UsernameTemplateMapper documented?
There is some generic info about broker mappers in identity broker 
chapter in 10.8 and 10.9 : 
http://keycloak.github.io/docs/userguide/keycloak-server/html/identity-broker.html#d4e2135 
. Besides that there are tooltips in admin console on details how to use 
various template tokens to generate username.
>
> I agree the only thing we need to do is in step 34 remove the "<IDP 
> alias>" prefix.
Created https://issues.jboss.org/browse/KEYCLOAK-2292 for 1.9

Marek
>
>
>     Marek
>>
>>     On 8 January 2016 at 12:32, Thomas Raehalme
>>     <thomas.raehalme at aitiofinland.com
>>     <mailto:thomas.raehalme at aitiofinland.com>> wrote:
>>
>>         Hi,
>>
>>         If I login to Keycloak using a federated identity such as
>>         Google, Keycloak inserts a prefix "google." to my username.
>>
>>         Maybe I'm missing something, but isn't this kind of
>>         unnecessary when the email address is already a unique property?
>>
>>         Best regards,
>>         Thomas
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/2c9c16e4/attachment.html