<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 16.7.2015 03:31, Scott Rossillo
wrote:<br>
</div>
<blockquote
cite="mid:CALAqdu9F=e81fbYADh2WB0LDc5D-rEfQnXsg4pb6p9f62jwc0A@mail.gmail.com"
type="cite">Why can't we just require email scope from upstream
IDPs? What system these days doesn't use email as some sort of
unique identifier, including Twitter and Github?<br>
</blockquote>
<br>
You should be surprised ;-). Some Oauth providers simply doesn't
have separate email scope, some of them doesn't return email at all
(twitter, StackOverflow), some of them doesn't return email in some
cases, eg. Github does not return email if user sets "Public email"
to "Don't show my email address" in his user profile Setting (which
looks like error for me that this setting affects REST API, but it
is how it works). Facebook user can deny providing email during
approving login for your server on Facebok's "Consent" page.<br>
<br>
Vl.<br>
<blockquote
cite="mid:CALAqdu9F=e81fbYADh2WB0LDc5D-rEfQnXsg4pb6p9f62jwc0A@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Jul 15, 2015 at 9:09 AM Bill Burke <<a
moz-do-not-send="true" href="mailto:bburke@redhat.com">bburke@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Looks like
IDP logins will require configurable auth flows too like<br>
registration and login currently have in master. Man, all
this stuff is<br>
going to be hard to get both easy to use and easy to extend.<br>
<br>
On 7/15/2015 4:40 AM, Vlastimil Elias wrote:<br>
> I agree also that solution with temporary user account is
not ideal.<br>
> Ideal solution (which I proposed originally) is to
present "Update<br>
> Account Page" as part of social registration flow before
KC DB account<br>
> is created. So you sort out all conflicts in this phase
and then create<br>
> final correct user or link social account to existing KC
account.<br>
><br>
> Vl.<br>
><br>
> On 15.7.2015 10:00, Stian Thorgersen wrote:<br>
>> After some thought I agree the proposal I made is way
to complicated. Implementing the migrate account feature would
be way to complicated, and probably not that often used.<br>
>><br>
>> I like the idea of having an option on an IdP to
trust email or not. We don't need that many options though, a
simple on/off toggle will be enough. When login using a new
IdP and email exists if this option is enabled we should just
add the link to the existing account, if it's disabled we
should just display the error message that email is already in
use (like we do now), but we can improve on that message to
make it more clear to the user what they have to do.<br>
>><br>
>> That won't solve the initial problem that sparked
this conservation though. If the user logs in with a IdP that
doesn't require email we can now ask the user to enter the
email address, but if they then add an email address that's
already in use there's not an easy way to recover from that.
Maybe that could be solved by not creating the account until
the user has performed the initial set of required actions on
a first login with IdP?<br>
>><br>
>> ----- Original Message -----<br>
>>> From: "Scott Rossillo" <<a
moz-do-not-send="true" href="mailto:srossillo@smartling.com"
target="_blank">srossillo@smartling.com</a>><br>
>>> To: "Bill Burke" <<a moz-do-not-send="true"
href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>,
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
>>> Sent: Tuesday, 14 July, 2015 9:16:12 PM<br>
>>> Subject: Re: [keycloak-dev] Improve first login
with identity provider<br>
>>><br>
>>> +1 for auto-merge. We modified the code to do
that.<br>
>>> I like Bill's approach with multiple options
though as this is the most<br>
>>> flexible and different people will have different
requirements.<br>
>>><br>
>>> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke <
<a moz-do-not-send="true" href="mailto:bburke@redhat.com"
target="_blank">bburke@redhat.com</a> > wrote:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On 7/14/2015 10:30 AM, Marek Posolda wrote:<br>
>>>> On 14.7.2015 15:15, Stian Thorgersen wrote:<br>
>>>>> ----- Original Message -----<br>
>>>>>> From: "Marek Posolda" < <a
moz-do-not-send="true" href="mailto:mposolda@redhat.com"
target="_blank">mposolda@redhat.com</a> ><br>
>>>>>> To: "Vlastimil Elias" < <a
moz-do-not-send="true" href="mailto:velias@redhat.com"
target="_blank">velias@redhat.com</a> >, <a
moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
>>>>>> Sent: Tuesday, 14 July, 2015 3:05:06
PM<br>
>>>>>> Subject: Re: [keycloak-dev] Improve
first login with identity provider<br>
>>>>>><br>
>>>>>> +1 for do it like this. It seems the
biggest challenge is merging the<br>
>>>>>> accounts. Not sure if it's better
creating temporary user accounts or<br>
>>>>>> rather keep all the state in
ClientSession. It seems the both approaches<br>
>>>>>> has pros and cons...<br>
>>>>>><br>
>>>>>> Do we want to support linking
multiple accounts during single<br>
>>>>>> authentication? It looks we should
support it too to have all the things<br>
>>>>>> covered properly. I mean the usecase
like:<br>
>>>>>><br>
>>>>>> 1) User is registered with
username/password and email " <a moz-do-not-send="true"
href="mailto:john@gmail.com" target="_blank">john@gmail.com</a>
"<br>
>>>>>> 2) User clicks to "Sign in with
Facebook" and authenticates. Keycloak<br>
>>>>>> displays "There is already account
with <a moz-do-not-send="true" href="mailto:john@gmail.com"
target="_blank">john@gmail.com</a> . Do you want to<br>
>>>>>> merge account?"<br>
>>>>>> 3) Now login screen is displayed
again (IMO it should be without<br>
>>>>>> Facebook button this time) and user
click to "Sign in with Google"<br>
>>>>>> 4) Keycloak again displays "There is
already account with<br>
>>>>>> <a moz-do-not-send="true"
href="mailto:john@gmail.com" target="_blank">john@gmail.com</a>
. Do you want to merge account?"<br>
>>>>>> 5) Now login screen is displayed
again (without both Facebook and Google<br>
>>>>>> buttons) and user finally login with
username/password . After<br>
>>>>>> authentication is user <a
moz-do-not-send="true" href="mailto:john@gmail.com"
target="_blank">john@gmail.com</a> linked with both Facebok
and Google<br>
>>>>> Yes, but I had a different approach in
mind:<br>
>>>>><br>
>>>>> 1) User is registered with
username/password and email " <a moz-do-not-send="true"
href="mailto:john@gmail.com" target="_blank">john@gmail.com</a>
"<br>
>>>>> 2) User clicks to "Sign in with Facebook"
and authenticates. Keycloak<br>
>>>>> creates the account, but sets the email
address ' <a moz-do-not-send="true"
href="mailto:john@gmail.com" target="_blank">john@gmail.com</a>
' as an<br>
>>>>> tmp attribute. Then it displays existing
account blah blah, do you want<br>
>>>>> to merge?<br>
>>>>> 3) User clicks merge and is shown a login
screen without username, but<br>
>>>>> only password (and any linked identity
providers)<br>
>>>>> 4) Once user is logged in the account
created in step 2 is merged with the<br>
>>>>> account created in step 1. After it's
merged the account from step 2 is<br>
>>>>> deleted.<br>
>>>>><br>
>>>>> This lets the user merge the account from
Facebook at any point as long as<br>
>>>>> it's within the expiration time. Newly
created (but not active accounts,<br>
>>>>> i.e. outstanding required actions) will
have a expiration time and be<br>
>>>>> removed by a background thread.<br>
>>>> Yeah, I agree with creating separate
temporary accounts. Was just<br>
>>>> wondering about use-case with chaining
multiple identity providers<br>
>>>> during single authentication (both Facebook
and Google). In this case,<br>
>>>> there will be 2 temporary accounts, so the
question is if:<br>
>>>> - The "facebook" temporary account is merged
with "google" temporary<br>
>>>> account after successful Google
authentication (my step 4)<br>
>>>> - Both "facebook" and "google" temporary
accounts are merged with the<br>
>>>> original <a moz-do-not-send="true"
href="mailto:john@gmail.com" target="_blank">john@gmail.com</a>
account after authentication is completely<br>
>>>> finished (my step 5)<br>
>>>><br>
>>>> but maybe this is implementation detail? Not
sure...<br>
>>>><br>
>>>> IMO the period for keep these temporary
accounts should be really small.<br>
>>>> I think user should finish the authentication
(which will delete<br>
>>>> temporary accounts) within minutes (not the
other day or so) and<br>
>>>> shouldn't never be assigned access token to.
Otherwise there might be<br>
>>>> issues with temporary account already linked
with some application data<br>
>>>> etc...<br>
>>>><br>
>>>> Also for your step (3), we don't want to be
limited just for the default<br>
>>>> password form right? I think that with
Authentication SPI, people may<br>
>>>> want various authentication mechanisms (maybe
some don't even want to<br>
>>>> use password at all). The tricky part is,
that username is already known<br>
>>>> and we want people to just provide
credentials (aka password) . But IMO<br>
>>>> if we limit only to form with password +
identity providers, the issue<br>
>>>> will return again after some time...<br>
>>>><br>
>>> This is WAY too complicated. Please see my long
previous email. There<br>
>>> should never be any temporary accounts. I'll
summarize my previous<br>
>>> email again:<br>
>>><br>
>>> * Existing accounts should only be detected by
email. "Bill Burke" gets<br>
>>> 56 million hits on Google. It is a very common
name.<br>
>>><br>
>>> Default behavior:<br>
>>> 1) User registers with " <a
moz-do-not-send="true" href="mailto:bburke@redhat.com"
target="_blank">bburke@redhat.com</a> " and password<br>
>>> 2) User does a social login, new account is
created " <a moz-do-not-send="true"
href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>
"<br>
>>> is stored in a user attribute. i.e. "Alternative
email".<br>
>>><br>
>>> Website requires linking:<br>
>>> 1) User registers with " <a
moz-do-not-send="true" href="mailto:bburke@redhat.com"
target="_blank">bburke@redhat.com</a> " and password<br>
>>> 2) User logins with Facebook, " <a
moz-do-not-send="true" href="mailto:bburke@redhat.com"
target="_blank">bburke@redhat.com</a> " exists. Prompted<br>
>>> "Account exists with same email you have
registered at Facebook. You<br>
>>> have been sent an email verification message.
Please follow the<br>
>>> directions of this email to login"<br>
>>> 3) User goes to Inbox, clicks link in email,
message screen appears<br>
>>> "Your Facebook account has been linked. Click
"Ok" to continue.". User<br>
>>> gets forwarded to website.<br>
>>> 4) Facebook is linked to pre-existing " <a
moz-do-not-send="true" href="mailto:bburke@redhat.com"
target="_blank">bburke@redhat.com</a> " account.<br>
>>><br>
>>> This would be implemented with Authentication
Flows. There would be no<br>
>>> temporary account. Step #2 would create a
ClientSession model and store<br>
>>> all the facebook metadata within it. Step #3
would import the facebook<br>
>>> metadata.<br>
>>><br>
>>> Alternatively, you could just trust the IDP and
do the link<br>
>>> automatically. Does Google et. al. send an
"email-verified" metadata?<br>
>>><br>
>>><br>
>>> User wants to link accounts:<br>
>>> 1) User goes to Account Service, Account LInking
page<br>
>>> 2) User is provided with list of IDPs i.e.
(Facebook, Google, etc). And<br>
>>> clicks one.<br>
>>> 3) User is prompted to login via that IDP<br>
>>> 4) User receives prompt "Your Facebook account
has been linked. Click<br>
>>> "OK" to continue". User gets forwarded to
website.<br>
>>><br>
>>> In this scenario, there is no removal of old
accounts. The initiating<br>
>>> account,X, would import the old Facebook account,
Y. X would create a<br>
>>> new federation link to Facebook. Y would be
disabled and its facebook<br>
>>> link removed. Y is marked as "merged" or "linked"
and points to account<br>
>>> X. You need to keep Y around as the user may have
done a bunch of<br>
>>> actions under that account...i.e. posted on <a
moz-do-not-send="true" href="http://jboss.org"
rel="noreferrer" target="_blank">jboss.org</a> forums.<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Bill Burke<br>
>>> JBoss, a division of Red Hat<br>
>>> <a moz-do-not-send="true"
href="http://bill.burkecentral.com" rel="noreferrer"
target="_blank">http://bill.burkecentral.com</a><br>
>>> _______________________________________________<br>
>>> keycloak-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
>>><br>
>>> _______________________________________________<br>
>>> keycloak-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
>> _______________________________________________<br>
>> keycloak-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a moz-do-not-send="true" href="http://bill.burkecentral.com"
rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team</pre>
</body>
</html>