ons, 14 09 2016 kl. 13:09 +0200, skrev Stian Thorgersen:
>
>
> On 14 September 2016 at 09:54, Tomas Groth Christensen <tgc@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev