<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 11, 2016 at 11:34 PM, Marek Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 08/01/16 13:05, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">It&#39;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&#39;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.
        <div><br>
        </div>
        <div>We could allow selecting the strategy to use. Then allow
          the user to change if there&#39;s a conflict. We already allow
          users to change email if there&#39;s a conflict so can do the same
          for username.</div>
      </div>
    </blockquote></span>
    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 ( <span style="background-color:#e4e4ff">UsernameTemplateMapper
      ). We don&#39;t need any other strategy IMO as the mapper is flexible
      enough.<br>
      <br>
      Maybe we can improve how is username generated if mapper is not
      used? Currently the username is generated based on algorithm like
      this:<br>
      1) If there is IdentityProviderMapper which sets username, it has
      priority<br>
      2) Otherwise if realm.isRegistrationEmailAsUsername, then email
      from social provider is used as username<br>
      3) Otherwise if username from Identity provider is set, we
      generate the keycloak username like &quot;&lt;IDP alias&gt;.&lt;IDP
      username&gt;&quot; (For example &quot;facebook.mposolda&quot; )<br>
      4) Otherwise if username from identity provider is null, we
      generate the keycloak username like </span><span style="background-color:#e4e4ff">&quot;&lt;IDP alias&gt;.&lt;IDP
      ID&gt;&quot; (For example &quot;facebook.12345&quot; )<br>
      <br>
      IMO the one thing, which can be improved is removing the IDP
      prefix in step 3 and use just the username &quot;mposolda&quot; . 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 &quot;12345&quot; is a bit confusing IMO.<br>
      </span></div><div bgcolor="#FFFFFF" text="#000000"><span style="background-color:#e4e4ff"><br></span></div></blockquote><div><br></div><div>+1 sounds good to me!</div><div><br></div><div>In case there&#39;s a conflict, I&#39;d appreciate if the user could either a) change username/password, or b) connect to an existing account. </div><div><br></div><div>Best regards,</div><div>Thomas</div><div><br></div><div> </div></div>
</div></div>