2:49 a.m.
We should improve the first login with identity provider flow as it's less than
elegant at the moment. Some of the suggestion below is how it already works and some not!
The mechanism to detect existing accounts should include:
* Username
* Email
* Firstname and lastname
This needs to work both initially on the callback from the identity provider, but also
after the user has updated the profile. If an existing account is detected the user should
be given the option to do one of the following:
* Cancel
* Merge - this will require the user to authenticate as the existing user. Once
authenticated the attributes, roles and identity-provider links from the new user are
copied to the existing user (not overriding existing attributes/roles/links)
* Continue - only if existing account is found by firstname and lastname
For this to work it's probably easier to initially always create the account. To get
around the case where email is duplicated we can set that as an temporary attribute rather
than the email.
We also need to make sure we can define what attributes are required for a user in a
realm, including validation of each attribute. If any of these attributes are missing the
user will have to update the profile.
Finally, we should add a expires on a user account. If a user initiates the login with an
identity provider, but never completes the above actions (for example closes the browser
on the existing account screen, or the update profile screen) the account should
automatically be removed after a given time.
With regards to required actions it should be possible to configure one or more required
actions for first login for a specific identity provider.
It would be nice to nail down this flow once and for all! If we can all agree on the flow,
we can allocate someone to implement it for 1.5.
4:22 a.m.
+1000 for all of these improvements
On 14.7.2015 09:49, Stian Thorgersen wrote:
We should improve the first login with identity provider flow as
it's less than elegant at the moment. Some of the suggestion below is how it already
works and some not!
The mechanism to detect existing accounts should include:
* Username
* Email
* Firstname and lastname
This needs to work both initially on the callback from the identity provider, but also
after the user has updated the profile. If an existing account is detected the user should
be given the option to do one of the following:
* Cancel
* Merge - this will require the user to authenticate as the existing user. Once
authenticated the attributes, roles and identity-provider links from the new user are
copied to the existing user (not overriding existing attributes/roles/links)
* Continue - only if existing account is found by firstname and lastname
For this to work it's probably easier to initially always create the account. To get
around the case where email is duplicated we can set that as an temporary attribute rather
than the email.
We also need to make sure we can define what attributes are required for a user in a
realm, including validation of each attribute. If any of these attributes are missing the
user will have to update the profile.
Finally, we should add a expires on a user account. If a user initiates the login with an
identity provider, but never completes the above actions (for example closes the browser
on the existing account screen, or the update profile screen) the account should
automatically be removed after a given time.
With regards to required actions it should be possible to configure one or more required
actions for first login for a specific identity provider.
It would be nice to nail down this flow once and for all! If we can all agree on the
flow, we can allocate someone to implement it for 1.5.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
8:05 a.m.
+1 for do it like this. It seems the biggest challenge is merging the
accounts. Not sure if it's better creating temporary user accounts or
rather keep all the state in ClientSession. It seems the both approaches
has pros and cons...
Do we want to support linking multiple accounts during single
authentication? It looks we should support it too to have all the things
covered properly. I mean the usecase like:
1) User is registered with username/password and email "john(a)gmail.com"
2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
displays "There is already account with john(a)gmail.com. Do you want to
merge account?"
3) Now login screen is displayed again (IMO it should be without
Facebook button this time) and user click to "Sign in with Google"
4) Keycloak again displays "There is already account with
john(a)gmail.com. Do you want to merge account?"
5) Now login screen is displayed again (without both Facebook and Google
buttons) and user finally login with username/password . After
authentication is user john(a)gmail.com linked with both Facebok and Google
Marek
On 14.7.2015 11:22, Vlastimil Elias wrote:
+1000 for all of these improvements
On 14.7.2015 09:49, Stian Thorgersen wrote:
> We should improve the first login with identity provider flow as it's less than
elegant at the moment. Some of the suggestion below is how it already works and some not!
>
> The mechanism to detect existing accounts should include:
>
> * Username
> * Email
> * Firstname and lastname
>
> This needs to work both initially on the callback from the identity provider, but
also after the user has updated the profile. If an existing account is detected the user
should be given the option to do one of the following:
>
> * Cancel
> * Merge - this will require the user to authenticate as the existing user. Once
authenticated the attributes, roles and identity-provider links from the new user are
copied to the existing user (not overriding existing attributes/roles/links)
> * Continue - only if existing account is found by firstname and lastname
>
> For this to work it's probably easier to initially always create the account. To
get around the case where email is duplicated we can set that as an temporary attribute
rather than the email.
>
> We also need to make sure we can define what attributes are required for a user in a
realm, including validation of each attribute. If any of these attributes are missing the
user will have to update the profile.
>
> Finally, we should add a expires on a user account. If a user initiates the login
with an identity provider, but never completes the above actions (for example closes the
browser on the existing account screen, or the update profile screen) the account should
automatically be removed after a given time.
>
> With regards to required actions it should be possible to configure one or more
required actions for first login for a specific identity provider.
>
> It would be nice to nail down this flow once and for all! If we can all agree on the
flow, we can allocate someone to implement it for 1.5.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:15 a.m.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Vlastimil Elias" <velias(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 14 July, 2015 3:05:06 PM
Subject: Re: [keycloak-dev] Improve first login with identity provider
+1 for do it like this. It seems the biggest challenge is merging the
accounts. Not sure if it's better creating temporary user accounts or
rather keep all the state in ClientSession. It seems the both approaches
has pros and cons...
Do we want to support linking multiple accounts during single
authentication? It looks we should support it too to have all the things
covered properly. I mean the usecase like:
1) User is registered with username/password and email "john(a)gmail.com"
2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
displays "There is already account with john(a)gmail.com. Do you want to
merge account?"
3) Now login screen is displayed again (IMO it should be without
Facebook button this time) and user click to "Sign in with Google"
4) Keycloak again displays "There is already account with
john(a)gmail.com. Do you want to merge account?"
5) Now login screen is displayed again (without both Facebook and Google
buttons) and user finally login with username/password . After
authentication is user john(a)gmail.com linked with both Facebok and Google
Yes, but I had a different approach in mind:
1) User is registered with username/password and email "john(a)gmail.com"
2) User clicks to "Sign in with Facebook" and authenticates. Keycloak creates
the account, but sets the email address 'john(a)gmail.com' as an tmp attribute. Then
it displays existing account blah blah, do you want to merge?
3) User clicks merge and is shown a login screen without username, but only password (and
any linked identity providers)
4) Once user is logged in the account created in step 2 is merged with the account created
in step 1. After it's merged the account from step 2 is deleted.
This lets the user merge the account from Facebook at any point as long as it's within
the expiration time. Newly created (but not active accounts, i.e. outstanding required
actions) will have a expiration time and be removed by a background thread.
Marek
On 14.7.2015 11:22, Vlastimil Elias wrote:
> +1000 for all of these improvements
>
> On 14.7.2015 09:49, Stian Thorgersen wrote:
>> We should improve the first login with identity provider flow as it's less
>> than elegant at the moment. Some of the suggestion below is how it
>> already works and some not!
>>
>> The mechanism to detect existing accounts should include:
>>
>> * Username
>> * Email
>> * Firstname and lastname
>>
>> This needs to work both initially on the callback from the identity
>> provider, but also after the user has updated the profile. If an existing
>> account is detected the user should be given the option to do one of the
>> following:
>>
>> * Cancel
>> * Merge - this will require the user to authenticate as the existing user.
>> Once authenticated the attributes, roles and identity-provider links from
>> the new user are copied to the existing user (not overriding existing
>> attributes/roles/links)
>> * Continue - only if existing account is found by firstname and lastname
>>
>> For this to work it's probably easier to initially always create the
>> account. To get around the case where email is duplicated we can set that
>> as an temporary attribute rather than the email.
>>
>> We also need to make sure we can define what attributes are required for a
>> user in a realm, including validation of each attribute. If any of these
>> attributes are missing the user will have to update the profile.
>>
>> Finally, we should add a expires on a user account. If a user initiates
>> the login with an identity provider, but never completes the above
>> actions (for example closes the browser on the existing account screen,
>> or the update profile screen) the account should automatically be removed
>> after a given time.
>>
>> With regards to required actions it should be possible to configure one or
>> more required actions for first login for a specific identity provider.
>>
>> It would be nice to nail down this flow once and for all! If we can all
>> agree on the flow, we can allocate someone to implement it for 1.5.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:52 a.m.
I'm not convinced this is a slam dunk. I think what you are suggesting
is a pain in the ass for users. Why would users ever care if accounts
are linked? I don't ever see social sites prompting me to merge or link
accounts. I have never linked social provider accounts on any website.
Users should never be prompted beyond the initial login for anything
if at all possible.
In most cases, I think the default behavior should be to just have
separate UserModels and store the email in an attribute. IMO, the vast
majority of applications will work in this manner. Linking will be
rare. IMO, I think jboss.org should work in this way too. WTF do users
care if their accounts are linked or not for JBoss.org? They probably
don't. And will probably be annoyed when they are required to do so.
IMO, only email should be used to detect existing accounts. Google
"Bill Burke" and you will get 56 million results. No, I'm not that
popular, but my name is! Also the username bburke, bill.burke, or
wburke is usually taken whenever I create an account on a social site.
There's really two scenarios here.
1) User login
2) User wants to link accounts in Account Service page.
For User login, there should be a global config page for IDP federation
with a "duplicate account policy" with these options:
* "None" - store email in an attribute
* "Prompt" - prompt user if they want to merge and require them to login
with the other accounts
* "Require" - require the user to merge their accounts
* "Trust" - trust the providers and automatically merge.
Each IDP could have a switch "Trusted". With options of "always",
"email-verified", "not-trusted".
For merging, IMO, UserModels should never be deleted. A user may have
made forum posts or done other actions under that userid. Instead that
UserModel should be disabled and linked to the master UserModel.
On 7/14/2015 3:49 AM, Stian Thorgersen wrote:
We should improve the first login with identity provider flow as
it's less than elegant at the moment. Some of the suggestion below is how it already
works and some not!
The mechanism to detect existing accounts should include:
* Username
* Email
* Firstname and lastname
This needs to work both initially on the callback from the identity provider, but also
after the user has updated the profile. If an existing account is detected the user should
be given the option to do one of the following:
* Cancel
* Merge - this will require the user to authenticate as the existing user. Once
authenticated the attributes, roles and identity-provider links from the new user are
copied to the existing user (not overriding existing attributes/roles/links)
* Continue - only if existing account is found by firstname and lastname
For this to work it's probably easier to initially always create the account. To get
around the case where email is duplicated we can set that as an temporary attribute rather
than the email.
We also need to make sure we can define what attributes are required for a user in a
realm, including validation of each attribute. If any of these attributes are missing the
user will have to update the profile.
Finally, we should add a expires on a user account. If a user initiates the login with an
identity provider, but never completes the above actions (for example closes the browser
on the existing account screen, or the update profile screen) the account should
automatically be removed after a given time.
With regards to required actions it should be possible to configure one or more required
actions for first login for a specific identity provider.
It would be nice to nail down this flow once and for all! If we can all agree on the
flow, we can allocate someone to implement it for 1.5.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:30 a.m.
On 14.7.2015 15:15, Stian Thorgersen wrote:
----- Original Message -----
> From: "Marek Posolda" <mposolda(a)redhat.com>
> To: "Vlastimil Elias" <velias(a)redhat.com>,
keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 14 July, 2015 3:05:06 PM
> Subject: Re: [keycloak-dev] Improve first login with identity provider
>
> +1 for do it like this. It seems the biggest challenge is merging the
> accounts. Not sure if it's better creating temporary user accounts or
> rather keep all the state in ClientSession. It seems the both approaches
> has pros and cons...
>
> Do we want to support linking multiple accounts during single
> authentication? It looks we should support it too to have all the things
> covered properly. I mean the usecase like:
>
> 1) User is registered with username/password and email "john(a)gmail.com"
> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
> displays "There is already account with john(a)gmail.com. Do you want to
> merge account?"
> 3) Now login screen is displayed again (IMO it should be without
> Facebook button this time) and user click to "Sign in with Google"
> 4) Keycloak again displays "There is already account with
> john(a)gmail.com. Do you want to merge account?"
> 5) Now login screen is displayed again (without both Facebook and Google
> buttons) and user finally login with username/password . After
> authentication is user john(a)gmail.com linked with both Facebok and Google
Yes, but I had a different approach in mind:
1) User is registered with username/password and email "john(a)gmail.com"
2) User clicks to "Sign in with Facebook" and authenticates. Keycloak creates
the account, but sets the email address 'john(a)gmail.com' as an tmp attribute. Then
it displays existing account blah blah, do you want to merge?
3) User clicks merge and is shown a login screen without username, but only password (and
any linked identity providers)
4) Once user is logged in the account created in step 2 is merged with the account
created in step 1. After it's merged the account from step 2 is deleted.
This lets the user merge the account from Facebook at any point as long as it's
within the expiration time. Newly created (but not active accounts, i.e. outstanding
required actions) will have a expiration time and be removed by a background thread.
Yeah, I agree with creating separate temporary accounts. Was just
wondering about use-case with chaining multiple identity providers
during single authentication (both Facebook and Google). In this case,
there will be 2 temporary accounts, so the question is if:
- The "facebook" temporary account is merged with "google" temporary
account after successful Google authentication (my step 4)
- Both "facebook" and "google" temporary accounts are merged with the
original john(a)gmail.com account after authentication is completely
finished (my step 5)
but maybe this is implementation detail? Not sure...
IMO the period for keep these temporary accounts should be really small.
I think user should finish the authentication (which will delete
temporary accounts) within minutes (not the other day or so) and
shouldn't never be assigned access token to. Otherwise there might be
issues with temporary account already linked with some application data
etc...
Also for your step (3), we don't want to be limited just for the default
password form right? I think that with Authentication SPI, people may
want various authentication mechanisms (maybe some don't even want to
use password at all). The tricky part is, that username is already known
and we want people to just provide credentials (aka password) . But IMO
if we limit only to form with password + identity providers, the issue
will return again after some time...
Marek
> Marek
>
> On 14.7.2015 11:22, Vlastimil Elias wrote:
>> +1000 for all of these improvements
>>
>> On 14.7.2015 09:49, Stian Thorgersen wrote:
>>> We should improve the first login with identity provider flow as it's
less
>>> than elegant at the moment. Some of the suggestion below is how it
>>> already works and some not!
>>>
>>> The mechanism to detect existing accounts should include:
>>>
>>> * Username
>>> * Email
>>> * Firstname and lastname
>>>
>>> This needs to work both initially on the callback from the identity
>>> provider, but also after the user has updated the profile. If an existing
>>> account is detected the user should be given the option to do one of the
>>> following:
>>>
>>> * Cancel
>>> * Merge - this will require the user to authenticate as the existing user.
>>> Once authenticated the attributes, roles and identity-provider links from
>>> the new user are copied to the existing user (not overriding existing
>>> attributes/roles/links)
>>> * Continue - only if existing account is found by firstname and lastname
>>>
>>> For this to work it's probably easier to initially always create the
>>> account. To get around the case where email is duplicated we can set that
>>> as an temporary attribute rather than the email.
>>>
>>> We also need to make sure we can define what attributes are required for a
>>> user in a realm, including validation of each attribute. If any of these
>>> attributes are missing the user will have to update the profile.
>>>
>>> Finally, we should add a expires on a user account. If a user initiates
>>> the login with an identity provider, but never completes the above
>>> actions (for example closes the browser on the existing account screen,
>>> or the update profile screen) the account should automatically be removed
>>> after a given time.
>>>
>>> With regards to required actions it should be possible to configure one or
>>> more required actions for first login for a specific identity provider.
>>>
>>> It would be nice to nail down this flow once and for all! If we can all
>>> agree on the flow, we can allocate someone to implement it for 1.5.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
10:11 a.m.
On 7/14/2015 10:30 AM, Marek Posolda wrote:
On 14.7.2015 15:15, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda(a)redhat.com>
>> To: "Vlastimil Elias" <velias(a)redhat.com>,
keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>> Subject: Re: [keycloak-dev] Improve first login with identity provider
>>
>> +1 for do it like this. It seems the biggest challenge is merging the
>> accounts. Not sure if it's better creating temporary user accounts or
>> rather keep all the state in ClientSession. It seems the both approaches
>> has pros and cons...
>>
>> Do we want to support linking multiple accounts during single
>> authentication? It looks we should support it too to have all the things
>> covered properly. I mean the usecase like:
>>
>> 1) User is registered with username/password and email
"john(a)gmail.com"
>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
>> displays "There is already account with john(a)gmail.com. Do you want to
>> merge account?"
>> 3) Now login screen is displayed again (IMO it should be without
>> Facebook button this time) and user click to "Sign in with Google"
>> 4) Keycloak again displays "There is already account with
>> john(a)gmail.com. Do you want to merge account?"
>> 5) Now login screen is displayed again (without both Facebook and Google
>> buttons) and user finally login with username/password . After
>> authentication is user john(a)gmail.com linked with both Facebok and Google
> Yes, but I had a different approach in mind:
>
> 1) User is registered with username/password and email "john(a)gmail.com"
> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
creates the account, but sets the email address 'john(a)gmail.com' as an tmp
attribute. Then it displays existing account blah blah, do you want to merge?
> 3) User clicks merge and is shown a login screen without username, but only password
(and any linked identity providers)
> 4) Once user is logged in the account created in step 2 is merged with the account
created in step 1. After it's merged the account from step 2 is deleted.
>
> This lets the user merge the account from Facebook at any point as long as it's
within the expiration time. Newly created (but not active accounts, i.e. outstanding
required actions) will have a expiration time and be removed by a background thread.
Yeah, I agree with creating separate temporary accounts. Was just
wondering about use-case with chaining multiple identity providers
during single authentication (both Facebook and Google). In this case,
there will be 2 temporary accounts, so the question is if:
- The "facebook" temporary account is merged with "google" temporary
account after successful Google authentication (my step 4)
- Both "facebook" and "google" temporary accounts are merged with
the
original john(a)gmail.com account after authentication is completely
finished (my step 5)
but maybe this is implementation detail? Not sure...
IMO the period for keep these temporary accounts should be really small.
I think user should finish the authentication (which will delete
temporary accounts) within minutes (not the other day or so) and
shouldn't never be assigned access token to. Otherwise there might be
issues with temporary account already linked with some application data
etc...
Also for your step (3), we don't want to be limited just for the default
password form right? I think that with Authentication SPI, people may
want various authentication mechanisms (maybe some don't even want to
use password at all). The tricky part is, that username is already known
and we want people to just provide credentials (aka password) . But IMO
if we limit only to form with password + identity providers, the issue
will return again after some time...
This is WAY too complicated. Please see my long previous email. There
should never be any temporary accounts. I'll summarize my previous
email again:
* Existing accounts should only be detected by email. "Bill Burke" gets
56 million hits on Google. It is a very common name.
Default behavior:
1) User registers with "bburke(a)redhat.com" and password
2) User does a social login, new account is created "bburke(a)redhat.com"
is stored in a user attribute. i.e. "Alternative email".
Website requires linking:
1) User registers with "bburke(a)redhat.com" and password
2) User logins with Facebook, "bburke(a)redhat.com" exists. Prompted
"Account exists with same email you have registered at Facebook. You
have been sent an email verification message. Please follow the
directions of this email to login"
3) User goes to Inbox, clicks link in email, message screen appears
"Your Facebook account has been linked. Click "Ok" to continue.".
User
gets forwarded to website.
4) Facebook is linked to pre-existing "bburke(a)redhat.com" account.
This would be implemented with Authentication Flows. There would be no
temporary account. Step #2 would create a ClientSession model and store
all the facebook metadata within it. Step #3 would import the facebook
metadata.
Alternatively, you could just trust the IDP and do the link
automatically. Does Google et. al. send an "email-verified" metadata?
User wants to link accounts:
1) User goes to Account Service, Account LInking page
2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And
clicks one.
3) User is prompted to login via that IDP
4) User receives prompt "Your Facebook account has been linked. Click
"OK" to continue". User gets forwarded to website.
In this scenario, there is no removal of old accounts. The initiating
account,X, would import the old Facebook account, Y. X would create a
new federation link to Facebook. Y would be disabled and its facebook
link removed. Y is marked as "merged" or "linked" and points to
account
X. You need to keep Y around as the user may have done a bunch of
actions under that account...i.e. posted on jboss.org forums.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:16 p.m.
+1 for auto-merge. We modified the code to do that.
I like Bill's approach with multiple options though as this is the most
flexible and different people will have different requirements.
On Tue, Jul 14, 2015 at 11:13 AM Bill Burke <bburke(a)redhat.com> wrote:
On 7/14/2015 10:30 AM, Marek Posolda wrote:
> On 14.7.2015 15:15, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda(a)redhat.com>
>>> To: "Vlastimil Elias" <velias(a)redhat.com>,
keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>>> Subject: Re: [keycloak-dev] Improve first login with identity provider
>>>
>>> +1 for do it like this. It seems the biggest challenge is merging the
>>> accounts. Not sure if it's better creating temporary user accounts or
>>> rather keep all the state in ClientSession. It seems the both
approaches
>>> has pros and cons...
>>>
>>> Do we want to support linking multiple accounts during single
>>> authentication? It looks we should support it too to have all the
things
>>> covered properly. I mean the usecase like:
>>>
>>> 1) User is registered with username/password and email "john(a)gmail.com
"
>>> 2) User clicks to "Sign in with Facebook" and authenticates.
Keycloak
>>> displays "There is already account with john(a)gmail.com. Do you want to
>>> merge account?"
>>> 3) Now login screen is displayed again (IMO it should be without
>>> Facebook button this time) and user click to "Sign in with
Google"
>>> 4) Keycloak again displays "There is already account with
>>> john(a)gmail.com. Do you want to merge account?"
>>> 5) Now login screen is displayed again (without both Facebook and
Google
>>> buttons) and user finally login with username/password . After
>>> authentication is user john(a)gmail.com linked with both Facebok and
Google
>> Yes, but I had a different approach in mind:
>>
>> 1) User is registered with username/password and email
"john(a)gmail.com"
>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
creates the account, but sets the email address 'john(a)gmail.com' as an
tmp attribute. Then it displays existing account blah blah, do you want to
merge?
>> 3) User clicks merge and is shown a login screen without username, but
only password (and any linked identity providers)
>> 4) Once user is logged in the account created in step 2 is merged with
the account created in step 1. After it's merged the account from step 2 is
deleted.
>>
>> This lets the user merge the account from Facebook at any point as long
as it's within the expiration time. Newly created (but not active accounts,
i.e. outstanding required actions) will have a expiration time and be
removed by a background thread.
> Yeah, I agree with creating separate temporary accounts. Was just
> wondering about use-case with chaining multiple identity providers
> during single authentication (both Facebook and Google). In this case,
> there will be 2 temporary accounts, so the question is if:
> - The "facebook" temporary account is merged with "google"
temporary
> account after successful Google authentication (my step 4)
> - Both "facebook" and "google" temporary accounts are merged
with the
> original john(a)gmail.com account after authentication is completely
> finished (my step 5)
>
> but maybe this is implementation detail? Not sure...
>
> IMO the period for keep these temporary accounts should be really small.
> I think user should finish the authentication (which will delete
> temporary accounts) within minutes (not the other day or so) and
> shouldn't never be assigned access token to. Otherwise there might be
> issues with temporary account already linked with some application data
> etc...
>
> Also for your step (3), we don't want to be limited just for the default
> password form right? I think that with Authentication SPI, people may
> want various authentication mechanisms (maybe some don't even want to
> use password at all). The tricky part is, that username is already known
> and we want people to just provide credentials (aka password) . But IMO
> if we limit only to form with password + identity providers, the issue
> will return again after some time...
>
This is WAY too complicated. Please see my long previous email. There
should never be any temporary accounts. I'll summarize my previous
email again:
* Existing accounts should only be detected by email. "Bill Burke" gets
56 million hits on Google. It is a very common name.
Default behavior:
1) User registers with "bburke(a)redhat.com" and password
2) User does a social login, new account is created "bburke(a)redhat.com"
is stored in a user attribute. i.e. "Alternative email".
Website requires linking:
1) User registers with "bburke(a)redhat.com" and password
2) User logins with Facebook, "bburke(a)redhat.com" exists. Prompted
"Account exists with same email you have registered at Facebook. You
have been sent an email verification message. Please follow the
directions of this email to login"
3) User goes to Inbox, clicks link in email, message screen appears
"Your Facebook account has been linked. Click "Ok" to continue.".
User
gets forwarded to website.
4) Facebook is linked to pre-existing "bburke(a)redhat.com" account.
This would be implemented with Authentication Flows. There would be no
temporary account. Step #2 would create a ClientSession model and store
all the facebook metadata within it. Step #3 would import the facebook
metadata.
Alternatively, you could just trust the IDP and do the link
automatically. Does Google et. al. send an "email-verified" metadata?
User wants to link accounts:
1) User goes to Account Service, Account LInking page
2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And
clicks one.
3) User is prompted to login via that IDP
4) User receives prompt "Your Facebook account has been linked. Click
"OK" to continue". User gets forwarded to website.
In this scenario, there is no removal of old accounts. The initiating
account,X, would import the old Facebook account, Y. X would create a
new federation link to Facebook. Y would be disabled and its facebook
link removed. Y is marked as "merged" or "linked" and points to
account
X. You need to keep Y around as the user may have done a bunch of
actions under that account...i.e. posted on jboss.org forums.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3 a.m.
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.
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.
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?
----- Original Message -----
From: "Scott Rossillo" <srossillo(a)smartling.com>
To: "Bill Burke" <bburke(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 14 July, 2015 9:16:12 PM
Subject: Re: [keycloak-dev] Improve first login with identity provider
+1 for auto-merge. We modified the code to do that.
I like Bill's approach with multiple options though as this is the most
flexible and different people will have different requirements.
On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < bburke(a)redhat.com > wrote:
On 7/14/2015 10:30 AM, Marek Posolda wrote:
> On 14.7.2015 15:15, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" < mposolda(a)redhat.com >
>>> To: "Vlastimil Elias" < velias(a)redhat.com >,
keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>>> Subject: Re: [keycloak-dev] Improve first login with identity provider
>>>
>>> +1 for do it like this. It seems the biggest challenge is merging the
>>> accounts. Not sure if it's better creating temporary user accounts or
>>> rather keep all the state in ClientSession. It seems the both approaches
>>> has pros and cons...
>>>
>>> Do we want to support linking multiple accounts during single
>>> authentication? It looks we should support it too to have all the things
>>> covered properly. I mean the usecase like:
>>>
>>> 1) User is registered with username/password and email " john(a)gmail.com
"
>>> 2) User clicks to "Sign in with Facebook" and authenticates.
Keycloak
>>> displays "There is already account with john(a)gmail.com . Do you want
to
>>> merge account?"
>>> 3) Now login screen is displayed again (IMO it should be without
>>> Facebook button this time) and user click to "Sign in with
Google"
>>> 4) Keycloak again displays "There is already account with
>>> john(a)gmail.com . Do you want to merge account?"
>>> 5) Now login screen is displayed again (without both Facebook and Google
>>> buttons) and user finally login with username/password . After
>>> authentication is user john(a)gmail.com linked with both Facebok and Google
>> Yes, but I had a different approach in mind:
>>
>> 1) User is registered with username/password and email " john(a)gmail.com
"
>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
>> creates the account, but sets the email address ' john(a)gmail.com ' as
an
>> tmp attribute. Then it displays existing account blah blah, do you want
>> to merge?
>> 3) User clicks merge and is shown a login screen without username, but
>> only password (and any linked identity providers)
>> 4) Once user is logged in the account created in step 2 is merged with the
>> account created in step 1. After it's merged the account from step 2 is
>> deleted.
>>
>> This lets the user merge the account from Facebook at any point as long as
>> it's within the expiration time. Newly created (but not active accounts,
>> i.e. outstanding required actions) will have a expiration time and be
>> removed by a background thread.
> Yeah, I agree with creating separate temporary accounts. Was just
> wondering about use-case with chaining multiple identity providers
> during single authentication (both Facebook and Google). In this case,
> there will be 2 temporary accounts, so the question is if:
> - The "facebook" temporary account is merged with "google"
temporary
> account after successful Google authentication (my step 4)
> - Both "facebook" and "google" temporary accounts are merged
with the
> original john(a)gmail.com account after authentication is completely
> finished (my step 5)
>
> but maybe this is implementation detail? Not sure...
>
> IMO the period for keep these temporary accounts should be really small.
> I think user should finish the authentication (which will delete
> temporary accounts) within minutes (not the other day or so) and
> shouldn't never be assigned access token to. Otherwise there might be
> issues with temporary account already linked with some application data
> etc...
>
> Also for your step (3), we don't want to be limited just for the default
> password form right? I think that with Authentication SPI, people may
> want various authentication mechanisms (maybe some don't even want to
> use password at all). The tricky part is, that username is already known
> and we want people to just provide credentials (aka password) . But IMO
> if we limit only to form with password + identity providers, the issue
> will return again after some time...
>
This is WAY too complicated. Please see my long previous email. There
should never be any temporary accounts. I'll summarize my previous
email again:
* Existing accounts should only be detected by email. "Bill Burke" gets
56 million hits on Google. It is a very common name.
Default behavior:
1) User registers with " bburke(a)redhat.com " and password
2) User does a social login, new account is created " bburke(a)redhat.com "
is stored in a user attribute. i.e. "Alternative email".
Website requires linking:
1) User registers with " bburke(a)redhat.com " and password
2) User logins with Facebook, " bburke(a)redhat.com " exists. Prompted
"Account exists with same email you have registered at Facebook. You
have been sent an email verification message. Please follow the
directions of this email to login"
3) User goes to Inbox, clicks link in email, message screen appears
"Your Facebook account has been linked. Click "Ok" to continue.".
User
gets forwarded to website.
4) Facebook is linked to pre-existing " bburke(a)redhat.com " account.
This would be implemented with Authentication Flows. There would be no
temporary account. Step #2 would create a ClientSession model and store
all the facebook metadata within it. Step #3 would import the facebook
metadata.
Alternatively, you could just trust the IDP and do the link
automatically. Does Google et. al. send an "email-verified" metadata?
User wants to link accounts:
1) User goes to Account Service, Account LInking page
2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And
clicks one.
3) User is prompted to login via that IDP
4) User receives prompt "Your Facebook account has been linked. Click
"OK" to continue". User gets forwarded to website.
In this scenario, there is no removal of old accounts. The initiating
account,X, would import the old Facebook account, Y. X would create a
new federation link to Facebook. Y would be disabled and its facebook
link removed. Y is marked as "merged" or "linked" and points to
account
X. You need to keep Y around as the user may have done a bunch of
actions under that account...i.e. posted on jboss.org forums.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:04 a.m.
Hi Bill,
I agree that account duplicity checking should be based on email only.
My question is which flow will be applied in case if social IdP do not
provide an email (it is a case for many Idp like Twitter, Github etc)
but email is mandatory in Keycloak?
User is asked to insert his email on "Update Your Account" page which is
now implemented as "login action" which means that KC user account
already exists in this phase.
What to do if email duplicity is detected in this phase? Or do you plan
to move "Update Your Account" page earlier into reg flow before user
account is created in KC DB?
I do not see description of this flow in any of your two emails in this
thread but it have to be resolved somehow.
See detailed problem description in
https://issues.jboss.org/browse/KEYCLOAK-1540 - this is real problem
reported by user of Red Hat Developer site.
Thanks
Vlastimil
On 14.7.2015 17:11, Bill Burke wrote:
On 7/14/2015 10:30 AM, Marek Posolda wrote:
> On 14.7.2015 15:15, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda(a)redhat.com>
>>> To: "Vlastimil Elias" <velias(a)redhat.com>,
keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>>> Subject: Re: [keycloak-dev] Improve first login with identity provider
>>>
>>> +1 for do it like this. It seems the biggest challenge is merging the
>>> accounts. Not sure if it's better creating temporary user accounts or
>>> rather keep all the state in ClientSession. It seems the both approaches
>>> has pros and cons...
>>>
>>> Do we want to support linking multiple accounts during single
>>> authentication? It looks we should support it too to have all the things
>>> covered properly. I mean the usecase like:
>>>
>>> 1) User is registered with username/password and email
"john(a)gmail.com"
>>> 2) User clicks to "Sign in with Facebook" and authenticates.
Keycloak
>>> displays "There is already account with john(a)gmail.com. Do you want to
>>> merge account?"
>>> 3) Now login screen is displayed again (IMO it should be without
>>> Facebook button this time) and user click to "Sign in with Google"
>>> 4) Keycloak again displays "There is already account with
>>> john(a)gmail.com. Do you want to merge account?"
>>> 5) Now login screen is displayed again (without both Facebook and Google
>>> buttons) and user finally login with username/password . After
>>> authentication is user john(a)gmail.com linked with both Facebok and Google
>> Yes, but I had a different approach in mind:
>>
>> 1) User is registered with username/password and email
"john(a)gmail.com"
>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak
creates the account, but sets the email address 'john(a)gmail.com' as an tmp
attribute. Then it displays existing account blah blah, do you want to merge?
>> 3) User clicks merge and is shown a login screen without username, but only
password (and any linked identity providers)
>> 4) Once user is logged in the account created in step 2 is merged with the
account created in step 1. After it's merged the account from step 2 is deleted.
>>
>> This lets the user merge the account from Facebook at any point as long as
it's within the expiration time. Newly created (but not active accounts, i.e.
outstanding required actions) will have a expiration time and be removed by a background
thread.
> Yeah, I agree with creating separate temporary accounts. Was just
> wondering about use-case with chaining multiple identity providers
> during single authentication (both Facebook and Google). In this case,
> there will be 2 temporary accounts, so the question is if:
> - The "facebook" temporary account is merged with "google"
temporary
> account after successful Google authentication (my step 4)
> - Both "facebook" and "google" temporary accounts are merged with
the
> original john(a)gmail.com account after authentication is completely
> finished (my step 5)
>
> but maybe this is implementation detail? Not sure...
>
> IMO the period for keep these temporary accounts should be really small.
> I think user should finish the authentication (which will delete
> temporary accounts) within minutes (not the other day or so) and
> shouldn't never be assigned access token to. Otherwise there might be
> issues with temporary account already linked with some application data
> etc...
>
> Also for your step (3), we don't want to be limited just for the default
> password form right? I think that with Authentication SPI, people may
> want various authentication mechanisms (maybe some don't even want to
> use password at all). The tricky part is, that username is already known
> and we want people to just provide credentials (aka password) . But IMO
> if we limit only to form with password + identity providers, the issue
> will return again after some time...
>
This is WAY too complicated. Please see my long previous email. There
should never be any temporary accounts. I'll summarize my previous
email again:
* Existing accounts should only be detected by email. "Bill Burke" gets
56 million hits on Google. It is a very common name.
Default behavior:
1) User registers with "bburke(a)redhat.com" and password
2) User does a social login, new account is created "bburke(a)redhat.com"
is stored in a user attribute. i.e. "Alternative email".
Website requires linking:
1) User registers with "bburke(a)redhat.com" and password
2) User logins with Facebook, "bburke(a)redhat.com" exists. Prompted
"Account exists with same email you have registered at Facebook. You
have been sent an email verification message. Please follow the
directions of this email to login"
3) User goes to Inbox, clicks link in email, message screen appears
"Your Facebook account has been linked. Click "Ok" to continue.".
User
gets forwarded to website.
4) Facebook is linked to pre-existing "bburke(a)redhat.com" account.
This would be implemented with Authentication Flows. There would be no
temporary account. Step #2 would create a ClientSession model and store
all the facebook metadata within it. Step #3 would import the facebook
metadata.
Alternatively, you could just trust the IDP and do the link
automatically. Does Google et. al. send an "email-verified" metadata?
User wants to link accounts:
1) User goes to Account Service, Account LInking page
2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And
clicks one.
3) User is prompted to login via that IDP
4) User receives prompt "Your Facebook account has been linked. Click
"OK" to continue". User gets forwarded to website.
In this scenario, there is no removal of old accounts. The initiating
account,X, would import the old Facebook account, Y. X would create a
new federation link to Facebook. Y would be disabled and its facebook
link removed. Y is marked as "merged" or "linked" and points to
account
X. You need to keep Y around as the user may have done a bunch of
actions under that account...i.e. posted on jboss.org forums.
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
3:37 a.m.
On 14.7.2015 15:52, Bill Burke wrote:
I'm not convinced this is a slam dunk. I think what you are
suggesting
is a pain in the ass for users. Why would users ever care if accounts
are linked? I don't ever see social sites prompting me to merge or link
accounts. I have never linked social provider accounts on any website.
Users should never be prompted beyond the initial login for anything
if at all possible.
In most cases, I think the default behavior should be to just have
separate UserModels and store the email in an attribute. IMO, the vast
majority of applications will work in this manner. Linking will be
rare. IMO, I think jboss.org should work in this way too. WTF do users
care if their accounts are linked or not for JBoss.org?
Because you lost all your historical data if you start to use new
account created over social login without linking.
And you are also forced to enter another email address to this new
account if email uniqueness is required. Many peoples do not want to use
another email address.
I agree that this is typically not a problem for new sites which starts
with empty user base, but once you start to use KC with social linking
for older site with existing user base the problem is more urgent. And
also as your site will be older and users start to return to it after
longer time when they forgot they used it previously.
They probably
don't. And will probably be annoyed when they are required to do so.
IMO, only email should be used to detect existing accounts. Google
"Bill Burke" and you will get 56 million results. No, I'm not that
popular, but my name is! Also the username bburke, bill.burke, or
wburke is usually taken whenever I create an account on a social site.
There's really two scenarios here.
1) User login
2) User wants to link accounts in Account Service page.
For User login, there should be a global config page for IDP federation
with a "duplicate account policy" with these options:
* "None" - store email in an attribute
* "Prompt" - prompt user if they want to merge and require them to login
with the other accounts
* "Require" - require the user to merge their accounts
* "Trust" - trust the providers and automatically merge.
Each IDP could have a switch "Trusted". With options of "always",
"email-verified", "not-trusted".
For merging, IMO, UserModels should never be deleted. A user may have
made forum posts or done other actions under that userid. Instead that
UserModel should be disabled and linked to the master UserModel.
On 7/14/2015 3:49 AM, Stian Thorgersen wrote:
> We should improve the first login with identity provider flow as it's less than
elegant at the moment. Some of the suggestion below is how it already works and some not!
>
> The mechanism to detect existing accounts should include:
>
> * Username
> * Email
> * Firstname and lastname
>
> This needs to work both initially on the callback from the identity provider, but
also after the user has updated the profile. If an existing account is detected the user
should be given the option to do one of the following:
>
> * Cancel
> * Merge - this will require the user to authenticate as the existing user. Once
authenticated the attributes, roles and identity-provider links from the new user are
copied to the existing user (not overriding existing attributes/roles/links)
> * Continue - only if existing account is found by firstname and lastname
>
> For this to work it's probably easier to initially always create the account. To
get around the case where email is duplicated we can set that as an temporary attribute
rather than the email.
>
> We also need to make sure we can define what attributes are required for a user in a
realm, including validation of each attribute. If any of these attributes are missing the
user will have to update the profile.
>
> Finally, we should add a expires on a user account. If a user initiates the login
with an identity provider, but never completes the above actions (for example closes the
browser on the existing account screen, or the update profile screen) the account should
automatically be removed after a given time.
>
> With regards to required actions it should be possible to configure one or more
required actions for first login for a specific identity provider.
>
> It would be nice to nail down this flow once and for all! If we can all agree on the
flow, we can allocate someone to implement it for 1.5.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
3:40 a.m.
I agree also that solution with temporary user account is not ideal.
Ideal solution (which I proposed originally) is to present "Update
Account Page" as part of social registration flow before KC DB account
is created. So you sort out all conflicts in this phase and then create
final correct user or link social account to existing KC account.
Vl.
On 15.7.2015 10:00, Stian Thorgersen wrote:
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.
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.
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?
----- Original Message -----
> From: "Scott Rossillo" <srossillo(a)smartling.com>
> To: "Bill Burke" <bburke(a)redhat.com>, keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 14 July, 2015 9:16:12 PM
> Subject: Re: [keycloak-dev] Improve first login with identity provider
>
> +1 for auto-merge. We modified the code to do that.
> I like Bill's approach with multiple options though as this is the most
> flexible and different people will have different requirements.
>
> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < bburke(a)redhat.com > wrote:
>
>
>
>
> On 7/14/2015 10:30 AM, Marek Posolda wrote:
>> On 14.7.2015 15:15, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Marek Posolda" < mposolda(a)redhat.com >
>>>> To: "Vlastimil Elias" < velias(a)redhat.com >,
keycloak-dev(a)lists.jboss.org
>>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>>>> Subject: Re: [keycloak-dev] Improve first login with identity provider
>>>>
>>>> +1 for do it like this. It seems the biggest challenge is merging the
>>>> accounts. Not sure if it's better creating temporary user accounts
or
>>>> rather keep all the state in ClientSession. It seems the both approaches
>>>> has pros and cons...
>>>>
>>>> Do we want to support linking multiple accounts during single
>>>> authentication? It looks we should support it too to have all the things
>>>> covered properly. I mean the usecase like:
>>>>
>>>> 1) User is registered with username/password and email "
john(a)gmail.com "
>>>> 2) User clicks to "Sign in with Facebook" and authenticates.
Keycloak
>>>> displays "There is already account with john(a)gmail.com . Do you want
to
>>>> merge account?"
>>>> 3) Now login screen is displayed again (IMO it should be without
>>>> Facebook button this time) and user click to "Sign in with
Google"
>>>> 4) Keycloak again displays "There is already account with
>>>> john(a)gmail.com . Do you want to merge account?"
>>>> 5) Now login screen is displayed again (without both Facebook and Google
>>>> buttons) and user finally login with username/password . After
>>>> authentication is user john(a)gmail.com linked with both Facebok and
Google
>>> Yes, but I had a different approach in mind:
>>>
>>> 1) User is registered with username/password and email " john(a)gmail.com
"
>>> 2) User clicks to "Sign in with Facebook" and authenticates.
Keycloak
>>> creates the account, but sets the email address ' john(a)gmail.com ' as
an
>>> tmp attribute. Then it displays existing account blah blah, do you want
>>> to merge?
>>> 3) User clicks merge and is shown a login screen without username, but
>>> only password (and any linked identity providers)
>>> 4) Once user is logged in the account created in step 2 is merged with the
>>> account created in step 1. After it's merged the account from step 2 is
>>> deleted.
>>>
>>> This lets the user merge the account from Facebook at any point as long as
>>> it's within the expiration time. Newly created (but not active accounts,
>>> i.e. outstanding required actions) will have a expiration time and be
>>> removed by a background thread.
>> Yeah, I agree with creating separate temporary accounts. Was just
>> wondering about use-case with chaining multiple identity providers
>> during single authentication (both Facebook and Google). In this case,
>> there will be 2 temporary accounts, so the question is if:
>> - The "facebook" temporary account is merged with "google"
temporary
>> account after successful Google authentication (my step 4)
>> - Both "facebook" and "google" temporary accounts are merged
with the
>> original john(a)gmail.com account after authentication is completely
>> finished (my step 5)
>>
>> but maybe this is implementation detail? Not sure...
>>
>> IMO the period for keep these temporary accounts should be really small.
>> I think user should finish the authentication (which will delete
>> temporary accounts) within minutes (not the other day or so) and
>> shouldn't never be assigned access token to. Otherwise there might be
>> issues with temporary account already linked with some application data
>> etc...
>>
>> Also for your step (3), we don't want to be limited just for the default
>> password form right? I think that with Authentication SPI, people may
>> want various authentication mechanisms (maybe some don't even want to
>> use password at all). The tricky part is, that username is already known
>> and we want people to just provide credentials (aka password) . But IMO
>> if we limit only to form with password + identity providers, the issue
>> will return again after some time...
>>
> This is WAY too complicated. Please see my long previous email. There
> should never be any temporary accounts. I'll summarize my previous
> email again:
>
> * Existing accounts should only be detected by email. "Bill Burke" gets
> 56 million hits on Google. It is a very common name.
>
> Default behavior:
> 1) User registers with " bburke(a)redhat.com " and password
> 2) User does a social login, new account is created " bburke(a)redhat.com "
> is stored in a user attribute. i.e. "Alternative email".
>
> Website requires linking:
> 1) User registers with " bburke(a)redhat.com " and password
> 2) User logins with Facebook, " bburke(a)redhat.com " exists. Prompted
> "Account exists with same email you have registered at Facebook. You
> have been sent an email verification message. Please follow the
> directions of this email to login"
> 3) User goes to Inbox, clicks link in email, message screen appears
> "Your Facebook account has been linked. Click "Ok" to continue.".
User
> gets forwarded to website.
> 4) Facebook is linked to pre-existing " bburke(a)redhat.com " account.
>
> This would be implemented with Authentication Flows. There would be no
> temporary account. Step #2 would create a ClientSession model and store
> all the facebook metadata within it. Step #3 would import the facebook
> metadata.
>
> Alternatively, you could just trust the IDP and do the link
> automatically. Does Google et. al. send an "email-verified" metadata?
>
>
> User wants to link accounts:
> 1) User goes to Account Service, Account LInking page
> 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And
> clicks one.
> 3) User is prompted to login via that IDP
> 4) User receives prompt "Your Facebook account has been linked. Click
> "OK" to continue". User gets forwarded to website.
>
> In this scenario, there is no removal of old accounts. The initiating
> account,X, would import the old Facebook account, Y. X would create a
> new federation link to Facebook. Y would be disabled and its facebook
> link removed. Y is marked as "merged" or "linked" and points to
account
> X. You need to keep Y around as the user may have done a bunch of
> actions under that account...i.e. posted on jboss.org forums.
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
8:08 a.m.
Looks like IDP logins will require configurable auth flows too like
registration and login currently have in master. Man, all this stuff is
going to be hard to get both easy to use and easy to extend.
On 7/15/2015 4:40 AM, Vlastimil Elias wrote:
I agree also that solution with temporary user account is not ideal.
Ideal solution (which I proposed originally) is to present "Update
Account Page" as part of social registration flow before KC DB account
is created. So you sort out all conflicts in this phase and then create
final correct user or link social account to existing KC account.
Vl.
On 15.7.2015 10:00, Stian Thorgersen wrote:
> 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.
>
> 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.
>
> 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?
>
> ----- Original Message -----
>> From: "Scott Rossillo" <srossillo(a)smartling.com>
>> To: "Bill Burke" <bburke(a)redhat.com>,
keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 14 July, 2015 9:16:12 PM
>> Subject: Re: [keycloak-dev] Improve first login with identity provider
>>
>> +1 for auto-merge. We modified the code to do that.
>> I like Bill's approach with multiple options though as this is the most
>> flexible and different people will have different requirements.
>>
>> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < bburke(a)redhat.com > wrote:
>>
>>
>>
>>
>> On 7/14/2015 10:30 AM, Marek Posolda wrote:
>>> On 14.7.2015 15:15, Stian Thorgersen wrote:
>>>> ----- Original Message -----
>>>>> From: "Marek Posolda" < mposolda(a)redhat.com >
>>>>> To: "Vlastimil Elias" < velias(a)redhat.com >,
keycloak-dev(a)lists.jboss.org
>>>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>>>>> Subject: Re: [keycloak-dev] Improve first login with identity
provider
>>>>>
>>>>> +1 for do it like this. It seems the biggest challenge is merging
the
>>>>> accounts. Not sure if it's better creating temporary user
accounts or
>>>>> rather keep all the state in ClientSession. It seems the both
approaches
>>>>> has pros and cons...
>>>>>
>>>>> Do we want to support linking multiple accounts during single
>>>>> authentication? It looks we should support it too to have all the
things
>>>>> covered properly. I mean the usecase like:
>>>>>
>>>>> 1) User is registered with username/password and email "
john(a)gmail.com "
>>>>> 2) User clicks to "Sign in with Facebook" and
authenticates. Keycloak
>>>>> displays "There is already account with john(a)gmail.com . Do you
want to
>>>>> merge account?"
>>>>> 3) Now login screen is displayed again (IMO it should be without
>>>>> Facebook button this time) and user click to "Sign in with
Google"
>>>>> 4) Keycloak again displays "There is already account with
>>>>> john(a)gmail.com . Do you want to merge account?"
>>>>> 5) Now login screen is displayed again (without both Facebook and
Google
>>>>> buttons) and user finally login with username/password . After
>>>>> authentication is user john(a)gmail.com linked with both Facebok and
Google
>>>> Yes, but I had a different approach in mind:
>>>>
>>>> 1) User is registered with username/password and email "
john(a)gmail.com "
>>>> 2) User clicks to "Sign in with Facebook" and authenticates.
Keycloak
>>>> creates the account, but sets the email address ' john(a)gmail.com
' as an
>>>> tmp attribute. Then it displays existing account blah blah, do you want
>>>> to merge?
>>>> 3) User clicks merge and is shown a login screen without username, but
>>>> only password (and any linked identity providers)
>>>> 4) Once user is logged in the account created in step 2 is merged with
the
>>>> account created in step 1. After it's merged the account from step 2
is
>>>> deleted.
>>>>
>>>> This lets the user merge the account from Facebook at any point as long
as
>>>> it's within the expiration time. Newly created (but not active
accounts,
>>>> i.e. outstanding required actions) will have a expiration time and be
>>>> removed by a background thread.
>>> Yeah, I agree with creating separate temporary accounts. Was just
>>> wondering about use-case with chaining multiple identity providers
>>> during single authentication (both Facebook and Google). In this case,
>>> there will be 2 temporary accounts, so the question is if:
>>> - The "facebook" temporary account is merged with
"google" temporary
>>> account after successful Google authentication (my step 4)
>>> - Both "facebook" and "google" temporary accounts are
merged with the
>>> original john(a)gmail.com account after authentication is completely
>>> finished (my step 5)
>>>
>>> but maybe this is implementation detail? Not sure...
>>>
>>> IMO the period for keep these temporary accounts should be really small.
>>> I think user should finish the authentication (which will delete
>>> temporary accounts) within minutes (not the other day or so) and
>>> shouldn't never be assigned access token to. Otherwise there might be
>>> issues with temporary account already linked with some application data
>>> etc...
>>>
>>> Also for your step (3), we don't want to be limited just for the default
>>> password form right? I think that with Authentication SPI, people may
>>> want various authentication mechanisms (maybe some don't even want to
>>> use password at all). The tricky part is, that username is already known
>>> and we want people to just provide credentials (aka password) . But IMO
>>> if we limit only to form with password + identity providers, the issue
>>> will return again after some time...
>>>
>> This is WAY too complicated. Please see my long previous email. There
>> should never be any temporary accounts. I'll summarize my previous
>> email again:
>>
>> * Existing accounts should only be detected by email. "Bill Burke"
gets
>> 56 million hits on Google. It is a very common name.
>>
>> Default behavior:
>> 1) User registers with " bburke(a)redhat.com " and password
>> 2) User does a social login, new account is created " bburke(a)redhat.com
"
>> is stored in a user attribute. i.e. "Alternative email".
>>
>> Website requires linking:
>> 1) User registers with " bburke(a)redhat.com " and password
>> 2) User logins with Facebook, " bburke(a)redhat.com " exists. Prompted
>> "Account exists with same email you have registered at Facebook. You
>> have been sent an email verification message. Please follow the
>> directions of this email to login"
>> 3) User goes to Inbox, clicks link in email, message screen appears
>> "Your Facebook account has been linked. Click "Ok" to
continue.". User
>> gets forwarded to website.
>> 4) Facebook is linked to pre-existing " bburke(a)redhat.com " account.
>>
>> This would be implemented with Authentication Flows. There would be no
>> temporary account. Step #2 would create a ClientSession model and store
>> all the facebook metadata within it. Step #3 would import the facebook
>> metadata.
>>
>> Alternatively, you could just trust the IDP and do the link
>> automatically. Does Google et. al. send an "email-verified" metadata?
>>
>>
>> User wants to link accounts:
>> 1) User goes to Account Service, Account LInking page
>> 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And
>> clicks one.
>> 3) User is prompted to login via that IDP
>> 4) User receives prompt "Your Facebook account has been linked. Click
>> "OK" to continue". User gets forwarded to website.
>>
>> In this scenario, there is no removal of old accounts. The initiating
>> account,X, would import the old Facebook account, Y. X would create a
>> new federation link to Facebook. Y would be disabled and its facebook
>> link removed. Y is marked as "merged" or "linked" and points
to account
>> X. You need to keep Y around as the user may have done a bunch of
>> actions under that account...i.e. posted on jboss.org forums.
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:31 p.m.
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?
On Wed, Jul 15, 2015 at 9:09 AM Bill Burke <bburke(a)redhat.com> wrote:
Looks like IDP logins will require configurable auth flows too like
registration and login currently have in master. Man, all this stuff is
going to be hard to get both easy to use and easy to extend.
On 7/15/2015 4:40 AM, Vlastimil Elias wrote:
> I agree also that solution with temporary user account is not ideal.
> Ideal solution (which I proposed originally) is to present "Update
> Account Page" as part of social registration flow before KC DB account
> is created. So you sort out all conflicts in this phase and then create
> final correct user or link social account to existing KC account.
>
> Vl.
>
> On 15.7.2015 10:00, Stian Thorgersen wrote:
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> ----- Original Message -----
>>> From: "Scott Rossillo" <srossillo(a)smartling.com>
>>> To: "Bill Burke" <bburke(a)redhat.com>,
keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 14 July, 2015 9:16:12 PM
>>> Subject: Re: [keycloak-dev] Improve first login with identity provider
>>>
>>> +1 for auto-merge. We modified the code to do that.
>>> I like Bill's approach with multiple options though as this is the most
>>> flexible and different people will have different requirements.
>>>
>>> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < bburke(a)redhat.com >
wrote:
>>>
>>>
>>>
>>>
>>> On 7/14/2015 10:30 AM, Marek Posolda wrote:
>>>> On 14.7.2015 15:15, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Marek Posolda" < mposolda(a)redhat.com >
>>>>>> To: "Vlastimil Elias" < velias(a)redhat.com >,
keycloak-dev(a)lists.jboss.org
>>>>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>>>>>> Subject: Re: [keycloak-dev] Improve first login with identity
provider
>>>>>>
>>>>>> +1 for do it like this. It seems the biggest challenge is
merging
the
>>>>>> accounts. Not sure if it's better creating temporary user
accounts
or
>>>>>> rather keep all the state in ClientSession. It seems the both
approaches
>>>>>> has pros and cons...
>>>>>>
>>>>>> Do we want to support linking multiple accounts during single
>>>>>> authentication? It looks we should support it too to have all
the
things
>>>>>> covered properly. I mean the usecase like:
>>>>>>
>>>>>> 1) User is registered with username/password and email "
john(a)gmail.com "
>>>>>> 2) User clicks to "Sign in with Facebook" and
authenticates.
Keycloak
>>>>>> displays "There is already account with john(a)gmail.com . Do
you
want to
>>>>>> merge account?"
>>>>>> 3) Now login screen is displayed again (IMO it should be
without
>>>>>> Facebook button this time) and user click to "Sign in with
Google"
>>>>>> 4) Keycloak again displays "There is already account with
>>>>>> john(a)gmail.com . Do you want to merge account?"
>>>>>> 5) Now login screen is displayed again (without both Facebook
and
Google
>>>>>> buttons) and user finally login with username/password . After
>>>>>> authentication is user john(a)gmail.com linked with both Facebok
and
Google
>>>>> Yes, but I had a different approach in mind:
>>>>>
>>>>> 1) User is registered with username/password and email "
john(a)gmail.com "
>>>>> 2) User clicks to "Sign in with Facebook" and
authenticates. Keycloak
>>>>> creates the account, but sets the email address ' john(a)gmail.com
'
as an
>>>>> tmp attribute. Then it displays existing account blah blah, do you
want
>>>>> to merge?
>>>>> 3) User clicks merge and is shown a login screen without username,
but
>>>>> only password (and any linked identity providers)
>>>>> 4) Once user is logged in the account created in step 2 is merged
with the
>>>>> account created in step 1. After it's merged the account from
step 2
is
>>>>> deleted.
>>>>>
>>>>> This lets the user merge the account from Facebook at any point as
long as
>>>>> it's within the expiration time. Newly created (but not active
accounts,
>>>>> i.e. outstanding required actions) will have a expiration time and
be
>>>>> removed by a background thread.
>>>> Yeah, I agree with creating separate temporary accounts. Was just
>>>> wondering about use-case with chaining multiple identity providers
>>>> during single authentication (both Facebook and Google). In this case,
>>>> there will be 2 temporary accounts, so the question is if:
>>>> - The "facebook" temporary account is merged with
"google" temporary
>>>> account after successful Google authentication (my step 4)
>>>> - Both "facebook" and "google" temporary accounts
are merged with the
>>>> original john(a)gmail.com account after authentication is completely
>>>> finished (my step 5)
>>>>
>>>> but maybe this is implementation detail? Not sure...
>>>>
>>>> IMO the period for keep these temporary accounts should be really
small.
>>>> I think user should finish the authentication (which will delete
>>>> temporary accounts) within minutes (not the other day or so) and
>>>> shouldn't never be assigned access token to. Otherwise there might
be
>>>> issues with temporary account already linked with some application
data
>>>> etc...
>>>>
>>>> Also for your step (3), we don't want to be limited just for the
default
>>>> password form right? I think that with Authentication SPI, people may
>>>> want various authentication mechanisms (maybe some don't even want
to
>>>> use password at all). The tricky part is, that username is already
known
>>>> and we want people to just provide credentials (aka password) . But
IMO
>>>> if we limit only to form with password + identity providers, the issue
>>>> will return again after some time...
>>>>
>>> This is WAY too complicated. Please see my long previous email. There
>>> should never be any temporary accounts. I'll summarize my previous
>>> email again:
>>>
>>> * Existing accounts should only be detected by email. "Bill Burke"
gets
>>> 56 million hits on Google. It is a very common name.
>>>
>>> Default behavior:
>>> 1) User registers with " bburke(a)redhat.com " and password
>>> 2) User does a social login, new account is created "
bburke(a)redhat.com "
>>> is stored in a user attribute. i.e. "Alternative email".
>>>
>>> Website requires linking:
>>> 1) User registers with " bburke(a)redhat.com " and password
>>> 2) User logins with Facebook, " bburke(a)redhat.com " exists.
Prompted
>>> "Account exists with same email you have registered at Facebook. You
>>> have been sent an email verification message. Please follow the
>>> directions of this email to login"
>>> 3) User goes to Inbox, clicks link in email, message screen appears
>>> "Your Facebook account has been linked. Click "Ok" to
continue.". User
>>> gets forwarded to website.
>>> 4) Facebook is linked to pre-existing " bburke(a)redhat.com "
account.
>>>
>>> This would be implemented with Authentication Flows. There would be no
>>> temporary account. Step #2 would create a ClientSession model and store
>>> all the facebook metadata within it. Step #3 would import the facebook
>>> metadata.
>>>
>>> Alternatively, you could just trust the IDP and do the link
>>> automatically. Does Google et. al. send an "email-verified"
metadata?
>>>
>>>
>>> User wants to link accounts:
>>> 1) User goes to Account Service, Account LInking page
>>> 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And
>>> clicks one.
>>> 3) User is prompted to login via that IDP
>>> 4) User receives prompt "Your Facebook account has been linked. Click
>>> "OK" to continue". User gets forwarded to website.
>>>
>>> In this scenario, there is no removal of old accounts. The initiating
>>> account,X, would import the old Facebook account, Y. X would create a
>>> new federation link to Facebook. Y would be disabled and its facebook
>>> link removed. Y is marked as "merged" or "linked" and
points to account
>>> X. You need to keep Y around as the user may have done a bunch of
>>> actions under that account...i.e. posted on jboss.org forums.
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:38 a.m.
On 16.7.2015 03:31, Scott Rossillo wrote:
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?
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.
Vl.
On Wed, Jul 15, 2015 at 9:09 AM Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Looks like IDP logins will require configurable auth flows too like
registration and login currently have in master. Man, all this
stuff is
going to be hard to get both easy to use and easy to extend.
On 7/15/2015 4:40 AM, Vlastimil Elias wrote:
> I agree also that solution with temporary user account is not ideal.
> Ideal solution (which I proposed originally) is to present "Update
> Account Page" as part of social registration flow before KC DB
account
> is created. So you sort out all conflicts in this phase and then
create
> final correct user or link social account to existing KC account.
>
> Vl.
>
> On 15.7.2015 10:00, Stian Thorgersen wrote:
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> ----- Original Message -----
>>> From: "Scott Rossillo" <srossillo(a)smartling.com
<mailto:srossillo@smartling.com>>
>>> To: "Bill Burke" <bburke(a)redhat.com
<mailto:bburke@redhat.com>>, keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>> Sent: Tuesday, 14 July, 2015 9:16:12 PM
>>> Subject: Re: [keycloak-dev] Improve first login with identity
provider
>>>
>>> +1 for auto-merge. We modified the code to do that.
>>> I like Bill's approach with multiple options though as this is
the most
>>> flexible and different people will have different requirements.
>>>
>>> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke <
bburke(a)redhat.com <mailto:bburke@redhat.com> > wrote:
>>>
>>>
>>>
>>>
>>> On 7/14/2015 10:30 AM, Marek Posolda wrote:
>>>> On 14.7.2015 15:15, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Marek Posolda" < mposolda(a)redhat.com
<mailto:mposolda@redhat.com> >
>>>>>> To: "Vlastimil Elias" < velias(a)redhat.com
<mailto:velias@redhat.com> >, keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM
>>>>>> Subject: Re: [keycloak-dev] Improve first login with
identity provider
>>>>>>
>>>>>> +1 for do it like this. It seems the biggest challenge is
merging the
>>>>>> accounts. Not sure if it's better creating temporary
user
accounts or
>>>>>> rather keep all the state in ClientSession. It seems the
both approaches
>>>>>> has pros and cons...
>>>>>>
>>>>>> Do we want to support linking multiple accounts during
single
>>>>>> authentication? It looks we should support it too to have
all the things
>>>>>> covered properly. I mean the usecase like:
>>>>>>
>>>>>> 1) User is registered with username/password and email
"
john(a)gmail.com <mailto:john@gmail.com> "
>>>>>> 2) User clicks to "Sign in with Facebook" and
authenticates. Keycloak
>>>>>> displays "There is already account with john(a)gmail.com
<mailto:john@gmail.com> . Do you want to
>>>>>> merge account?"
>>>>>> 3) Now login screen is displayed again (IMO it should be
without
>>>>>> Facebook button this time) and user click to "Sign in
with
Google"
>>>>>> 4) Keycloak again displays "There is already account
with
>>>>>> john(a)gmail.com <mailto:john@gmail.com> . Do you want
to
merge account?"
>>>>>> 5) Now login screen is displayed again (without both
Facebook and Google
>>>>>> buttons) and user finally login with username/password .
After
>>>>>> authentication is user john(a)gmail.com
<mailto:john@gmail.com> linked with both Facebok and Google
>>>>> Yes, but I had a different approach in mind:
>>>>>
>>>>> 1) User is registered with username/password and email "
john(a)gmail.com <mailto:john@gmail.com> "
>>>>> 2) User clicks to "Sign in with Facebook" and
authenticates.
Keycloak
>>>>> creates the account, but sets the email address '
john(a)gmail.com <mailto:john@gmail.com> ' as an
>>>>> tmp attribute. Then it displays existing account blah blah,
do you want
>>>>> to merge?
>>>>> 3) User clicks merge and is shown a login screen without
username, but
>>>>> only password (and any linked identity providers)
>>>>> 4) Once user is logged in the account created in step 2 is
merged with the
>>>>> account created in step 1. After it's merged the account
from step 2 is
>>>>> deleted.
>>>>>
>>>>> This lets the user merge the account from Facebook at any
point as long as
>>>>> it's within the expiration time. Newly created (but not
active accounts,
>>>>> i.e. outstanding required actions) will have a expiration
time and be
>>>>> removed by a background thread.
>>>> Yeah, I agree with creating separate temporary accounts. Was just
>>>> wondering about use-case with chaining multiple identity
providers
>>>> during single authentication (both Facebook and Google). In
this case,
>>>> there will be 2 temporary accounts, so the question is if:
>>>> - The "facebook" temporary account is merged with
"google"
temporary
>>>> account after successful Google authentication (my step 4)
>>>> - Both "facebook" and "google" temporary
accounts are merged
with the
>>>> original john(a)gmail.com <mailto:john@gmail.com> account after
authentication is completely
>>>> finished (my step 5)
>>>>
>>>> but maybe this is implementation detail? Not sure...
>>>>
>>>> IMO the period for keep these temporary accounts should be
really small.
>>>> I think user should finish the authentication (which will delete
>>>> temporary accounts) within minutes (not the other day or so) and
>>>> shouldn't never be assigned access token to. Otherwise there
might be
>>>> issues with temporary account already linked with some
application data
>>>> etc...
>>>>
>>>> Also for your step (3), we don't want to be limited just for
the default
>>>> password form right? I think that with Authentication SPI,
people may
>>>> want various authentication mechanisms (maybe some don't even
want to
>>>> use password at all). The tricky part is, that username is
already known
>>>> and we want people to just provide credentials (aka password)
. But IMO
>>>> if we limit only to form with password + identity providers,
the issue
>>>> will return again after some time...
>>>>
>>> This is WAY too complicated. Please see my long previous
email. There
>>> should never be any temporary accounts. I'll summarize my previous
>>> email again:
>>>
>>> * Existing accounts should only be detected by email. "Bill
Burke" gets
>>> 56 million hits on Google. It is a very common name.
>>>
>>> Default behavior:
>>> 1) User registers with " bburke(a)redhat.com
<mailto:bburke@redhat.com> " and password
>>> 2) User does a social login, new account is created "
bburke(a)redhat.com <mailto:bburke@redhat.com> "
>>> is stored in a user attribute. i.e. "Alternative email".
>>>
>>> Website requires linking:
>>> 1) User registers with " bburke(a)redhat.com
<mailto:bburke@redhat.com> " and password
>>> 2) User logins with Facebook, " bburke(a)redhat.com
<mailto:bburke@redhat.com> " exists. Prompted
>>> "Account exists with same email you have registered at
Facebook. You
>>> have been sent an email verification message. Please follow the
>>> directions of this email to login"
>>> 3) User goes to Inbox, clicks link in email, message screen
appears
>>> "Your Facebook account has been linked. Click "Ok" to
continue.". User
>>> gets forwarded to website.
>>> 4) Facebook is linked to pre-existing " bburke(a)redhat.com
<mailto:bburke@redhat.com> " account.
>>>
>>> This would be implemented with Authentication Flows. There
would be no
>>> temporary account. Step #2 would create a ClientSession model
and store
>>> all the facebook metadata within it. Step #3 would import the
facebook
>>> metadata.
>>>
>>> Alternatively, you could just trust the IDP and do the link
>>> automatically. Does Google et. al. send an "email-verified"
metadata?
>>>
>>>
>>> User wants to link accounts:
>>> 1) User goes to Account Service, Account LInking page
>>> 2) User is provided with list of IDPs i.e. (Facebook, Google,
etc). And
>>> clicks one.
>>> 3) User is prompted to login via that IDP
>>> 4) User receives prompt "Your Facebook account has been
linked. Click
>>> "OK" to continue". User gets forwarded to website.
>>>
>>> In this scenario, there is no removal of old accounts. The
initiating
>>> account,X, would import the old Facebook account, Y. X would
create a
>>> new federation link to Facebook. Y would be disabled and its
facebook
>>> link removed. Y is marked as "merged" or "linked"
and points
to account
>>> X. You need to keep Y around as the user may have done a bunch of
>>> actions under that account...i.e. posted on jboss.org
<http://jboss.org> forums.
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
3204
days inactive
3206
days old
14 comments
5 participants
participants (5)
-
Bill Burke -
Marek Posolda -
Scott Rossillo -
Stian Thorgersen -
Vlastimil Elias