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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.

On 11 January 2016 at 22:34, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@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?

I agree the only thing we need to do is in step 34 remove the "<IDP alias>" prefix.

Marek > > On 8 January 2016 at 12:32, Thomas Raehalme > <thomas.raehalme(a)aitiofinland.com > <mailto:thomas.raehalme@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(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hi Thomas, When we started using keycloak for federated identity, we observed similar behavior but there is a work around to get away from this using mappers. It works like a charm for us without any prefix. MapperType : Username Template Importer Template : ${NAMEID} Best Kamal ------------------------------ *From:* Thomas Raehalme <thomas.raehalme(a)aitiofinland.com&gt; *To:* keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; *Sent:* Friday, January 8, 2016 6:32 AM *Subject:* [keycloak-dev] Why the provider prefix in username? 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev