<div dir="ltr"><div>FYI the relevant JIRA issue is:</div><div>KEYCLOAK-2141 - Contact email: <a href="https://issues.jboss.org/browse/KEYCLOAK-2141">https://issues.jboss.org/browse/KEYCLOAK-2141</a></div><div><br></div><div>Cheers,</div><div>Thomas</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-14 14:50 GMT+02:00 Tomas Groth Christensen <span dir="ltr"><<a href="mailto:tgc@dma.dk" target="_blank">tgc@dma.dk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">ons, 14 09 2016 kl. 13:09 +0200, skrev Stian Thorgersen:<br>
><br>
><br>
> On 14 September 2016 at 09:54, Tomas Groth Christensen <<a href="mailto:tgc@dma.dk">tgc@dma.dk</a>><br>
> wrote:<br>
> > Hi again,<br>
> ><br>
> > Thanks for the fast reply!<br>
> ><br>
> > ons, 14 09 2016 kl. 09:24 +0200, skrev Stian Thorgersen:<br>
> > > We are planning to introduce support for contact email in the<br>
> > > future. The current email field is both a login and a contact<br>
> > > email. As it's used for login it has to be unique.<br>
> > Do you have an approximate ETA for the contact email introduction?<br>
> ><br>
> Nope, wouldn't be until 2017 unless we get a community contribution.<br>
> <br>
<br>
</span>Ok, we'll wait and will use a workaround until then.<br>
<span class=""><br>
> ><br>
> > > You could probably work around it with custom mappers for your<br>
> > > IdPs that map email to an attribute rather than the user email<br>
> > > field. Then create a custom email sender to use the contact<br>
> > > attribute from the user rather than email field.<br>
> > While I can see that this would work, would this have any advantage<br>
> > over the "custom-authenticator-that-<wbr>deletes-existing-users-with-<br>
> > the-same-email" approach I mentioned? In my view using the "delete"<br>
> > approach is easier/faster to implement and would also requires<br>
> > fewer changes once the contact-email is introduced.<br>
> ><br>
> Deleting existing users doesn't make any sense to me. You're loosing<br>
> any changes for the user done through admin console or account<br>
> management. You'll end up invalidation existing sessions (for example<br>
> if a user wants to be logged-in concurrently from different IdPs).<br>
<br>
</span>Since the user information will come from Identity Providers that are<br>
expected to manage the user information and make sure it is correct and<br>
updated, overwriting "incoming" users should not be a problem in our<br>
case. For this reason we have also disabled account review in the<br>
first-login-flow.<br>
The invalidation of user sessions is of course a potential issue, which<br>
we will have to take into account.<br>
<span class=""><br>
><br>
> Another option you could look into is to have a protocol mapper that<br>
> tunes the token depending on what IdP was used. That would allow<br>
> account linking, but give different permissions based on how the user<br>
> was authenticated. Ability to support multiple authentication levels<br>
> is something we're also want to look at in 2017.<br>
> <br>
<br>
</span>This could work, but for me it seems more complicated than the<br>
(admittedly crude) delete-approach. And it might leave us with a setup<br>
that won't be easily reverted back to keycloaks standard solutions,<br>
when they arrive, hopefully in 2017. 2017 looks to be an (another)<br>
exiting year for keycloak :)<br>
<br>
We will discuss this internally and decide on which approach to use.<br>
Thank you for your help and input so far!<br>
<span class="HOEnZb"><font color="#888888"><br>
/Tomas<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a></div></div></blockquote></div><br></div>