<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 September 2016 at 09:54, Tomas Groth Christensen <span dir="ltr"><<a href="mailto:tgc@dma.dk" target="_blank">tgc@dma.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>Hi again,</div>
<div><br>
</div>
<div>Thanks for the fast reply!</div><span class="">
<div><br>
</div>
<div>ons, 14 09 2016 kl. 09:24 +0200, skrev Stian Thorgersen:</div>
<blockquote type="cite">
<div>We are planning to introduce support for contact email in the future. The current email field is both a login and a contact email. As it's used for login it has to be unique.</div>
</blockquote>
<div><br>
</div>
</span><div>Do you have an approximate ETA for the contact email introduction?</div></div></blockquote><div><br></div><div>Nope, wouldn't be until 2017 unless we get a community contribution.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span class="">
<div><br>
</div>
<blockquote type="cite">
<div>You could probably work around it with custom mappers for your IdPs that map email to an attribute rather than the user email field. Then create a custom email sender to use the contact attribute from the user rather than email field.</div>
</blockquote>
<div><br>
</div>
</span><div>While I can see that this would work, would this have any advantage over the "custom-authenticator-that-<wbr>deletes-existing-users-with-<wbr>the-same-email" approach I mentioned? In my view using the "delete" approach is easier/faster to implement and would also
requires fewer changes once the contact-email is introduced.</div></div></blockquote><div><br></div><div>Deleting existing users doesn't make any sense to me. You're loosing any changes for the user done through admin console or account management. You'll end up invalidation existing sessions (for example if a user wants to be logged-in concurrently from different IdPs).</div><div><br></div><div>Another option you could look into is to have a protocol mapper that tunes the token depending on what IdP was used. That would allow account linking, but give different permissions based on how the user was authenticated. Ability to support multiple authentication levels is something we're also want to look at in 2017.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><br>
</div>
<div>Best regards,</div>
<div>Tomas</div><div><div class="h5">
<div><br>
</div>
<div><br>
</div>
<blockquote type="cite">
<div><br>
</div>
<div>[1] <a href="https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/email/DefaultEmailSenderProvider.java" target="_blank">https://github.com/<wbr>keycloak/keycloak/blob/master/<wbr>services/src/main/java/org/<wbr>keycloak/email/<wbr>DefaultEmailSenderProvider.<wbr>java</a></div>
<div><br>
</div>
<div>On 14 September 2016 at 09:17, Tomas Groth Christensen <<a href="mailto:tgc@dma.dk" target="_blank">tgc@dma.dk</a>> wrote:</div>
<blockquote type="cite">
<div>Hi,</div>
<div><br>
</div>
<div>I'm involved in a project where we use Keycloak as Identity Broker, and</div>
<div>so far we've been very happy with Keycloak, and implemented a few SPIs</div>
<div>to do some special things, but now we've hit a snag...</div>
<div><br>
</div>
<div>In our setup we have many clients using the Identity Broker which then</div>
<div>again has many Identity Providers from which the user can chose one to</div>
<div>use for login.</div>
<div>Our problem is that the same user (using one email address) can exist</div>
<div>in 2 or more Identity Providers, and we do not want to link these</div>
<div>accounts. The reason for not linking the accounts is that the user can</div>
<div>be given special privileges in clients, based on which Identity</div>
<div>Provider the user comes from. These privileges should not be carried</div>
<div>over from one Identity Providers user to another since the same user</div>
<div>might be an administrator when coming the one Identity Provider and a</div>
<div>common user when coming from a different Identity Provider.</div>
<div><br>
</div>
<div>So, is it possible to allow multiple users to have the same email</div>
<div>address? Looking at the source code there are checks for duplicated</div>
<div>user-emails in most places where users are created... Could a solution</div>
<div>be to implement a custom authenticator that replaces</div>
<div>IdpCreateUserIfUniqueAuthentic<wbr>ator which does not check for duplicated</div>
<div>emails, or are there database constraints that will prohibit this?</div>
<div>An alternative solution could perhaps be a custom authenticator that</div>
<div>simply deletes existing users with the same email address?</div>
<div><br>
</div>
<div>I hope you can give me some pointer on how to proceed...</div>
<div><br>
</div>
<div><br>
</div>
<div>--</div>
<div>Best regards,</div>
<div>Tomas Groth Christensen</div>
<div>Softwaredeveloper</div>
<div>Danish Maritime Authority</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>______________________________<wbr>_________________</div>
<div>keycloak-dev mailing list</div>
<div><a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a></div>
<div><a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a></div>
<div><br>
</div>
</blockquote>
</blockquote>
</div></div></div>
</blockquote></div><br></div></div>