[keycloak-dev] Allow multiple users with the same email

[Thomas Darimont]

FYI the relevant JIRA issue is:
KEYCLOAK-2141 - Contact email: https://issues.jboss.org/browse/KEYCLOAK-2141

Cheers,
Thomas


2016-09-14 14:50 GMT+02:00 Tomas Groth Christensen <tgc at dma.dk>:

> ons, 14 09 2016 kl. 13:09 +0200, skrev Stian Thorgersen:
> >
> >
> > On 14 September 2016 at 09:54, Tomas Groth Christensen <tgc at dma.dk>
> > wrote:
> > > Hi again,
> > >
> > > Thanks for the fast reply!
> > >
> > > ons, 14 09 2016 kl. 09:24 +0200, skrev Stian Thorgersen:
> > > > 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.
> > > Do you have an approximate ETA for the contact email introduction?
> > >
> > Nope, wouldn't be until 2017 unless we get a community contribution.
> >
>
> Ok, we'll wait and will use a workaround until then.
>
> > >
> > > > 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.
> > > While I can see that this would work, would this have any advantage
> > > over the "custom-authenticator-that-deletes-existing-users-with-
> > > 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.
> > >
> > 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).
>
> Since the user information will come from Identity Providers that are
> expected to manage the user information and make sure it is correct and
> updated, overwriting "incoming" users should not be a problem in our
> case. For this reason we have also disabled account review in the
> first-login-flow.
> The invalidation of user sessions is of course a potential issue, which
> we will have to take into account.
>
> >
> > 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.
> >
>
> This could work, but for me it seems more complicated than the
> (admittedly crude) delete-approach. And it might leave us with a setup
> that won't be easily reverted back to keycloaks standard solutions,
> when they arrive, hopefully in 2017. 2017 looks to be an (another)
> exiting year for keycloak :)
>
> We will discuss this internally and decide on which approach to use.
> Thank you for your help and input so far!
>
> /Tomas
>
> _______________________________________________
> keycloak-dev mailing list
> 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/20160915/2cafbdb9/attachment-0001.html