3:33 a.m.
I went again through all the previous discussions, related JIRAs and
requirements. As of now, my plan is to:
- Use authentication SPI to handle the flow and related actions for
first social login. (Update user profile, Detect duplicated account,
Verify email or reauthenticate user if duplication is detected, Create
social link to existing account). This allows most flexibility for
admins to specify how exactly the linking should work
- Detecting duplication will be based on email only by default - (For
example duplication is detected if Facebook user with email
bob(a)gmail.com authenticates, but there is already Keycloak user with
email bob(a)gmail.com ). The people can provide their own execution if
they want different way for detect duplications
- It seems it's more proper to postpone creating user account later,
once we know that there is no duplication. In other words, if "Update
profile on first login" is enabled, the user account is not yet created
when the update profile page is shown. All the info related to
BrokeredIdentityContext stuff will be available on ClientSession. This
seems to me easier and more proper solution then creating temporary
account with email in some "temporary" attribute. Temporary accounts
have other challenges (Cleaner thread for delete outdated unmerged
accounts etc).
- If "trustEmail" flag is on for IdentityProvider, the provider link
will be created automatically. (For example if Facebook user
bob(a)gmail.com authenticates for the first time and there is already
Keycloak user with email bob(a)gmail.com and trustEmail is on, the
Facebook link is automatically created for Keycloak account
bob(a)gmail.com without any additional verification)
- If "trustEmail" flag is off, there would need to be other way to
verify user before creating social link. The user will first confirm if
he wants to merge the accounts. Then there will be either:
-- Email verification: The mail will be sent to bob(a)gmail.com like
"Someone authenticates to Keycloak server http://www.keycloak.org:8080
through Facebook account bob(a)gmail.com and wants to link Facebook
account with existing Keycloak account bob(a)gmail.com . If it is you,
click here" . After user clicks, the social link is created
-- Further authentication: User will need to authenticate to existing
bob(a)gmail.com keycloak account through password (or OTP or both or
something else)
All of this is configurable through flows, so admin can disable the "Do
you want to create social link?" screen, or enforce email verification
instead of authentication, configure required authenticators etc.
- I am not sure if we want to handle just merge with existing account
during first broker login, or if we also want to handle merging of
accounts in account management? For now, I am planning to handle just
the login flow and possibly address Account management later if there is
need for it. The merging accounts in account management might be quite a
challenge as there is merge of 2 already existing user accounts with
various issues related to it (Which roles/permissions should merged
account have? Which attributes it should have? Which federation link?
etc.). But at least, I am planning to address the issue with redirect to
login forms error screen instead of stay in account management -
https://issues.jboss.org/browse/KEYCLOAK-1822
Marek
8:05 a.m.
IMO, most applications will not care about account duplication. Most
users won't care about account linking. So, IMO:
1) users should not be required to link accounts. In the case where an
account cannot be automatically linked a duplicate account should be
created
2) Providers should be trusted by default. Trusted providers can just
automatically link themselves to existing accounts that were logged in
by other trusted providers.
3) Untrusted providers can automatically link if email has been verified
for all parties.
4) Users can merge accounts that have verified emails.
5) An alternative to user self merging of account could be requiring to
enter in a temporary code after logging into each account.
#1 and #2 can be added with minimal changes to code. #3 requires a flow
on broker login and a rework of the broker SPI. #4 is account service
changes. #5 might be as easy as adding a required action.
I guess it depends if ultimate flexibility is needed. #1, #2 and #4
might be enough and require the least amount of changes and SPI refactoring.
On 10/27/2015 4:33 AM, Marek Posolda wrote:
I went again through all the previous discussions, related JIRAs and
requirements. As of now, my plan is to:
- Use authentication SPI to handle the flow and related actions for
first social login. (Update user profile, Detect duplicated account,
Verify email or reauthenticate user if duplication is detected, Create
social link to existing account). This allows most flexibility for
admins to specify how exactly the linking should work
- Detecting duplication will be based on email only by default - (For
example duplication is detected if Facebook user with email
bob(a)gmail.com authenticates, but there is already Keycloak user with
email bob(a)gmail.com ). The people can provide their own execution if
they want different way for detect duplications
- It seems it's more proper to postpone creating user account later,
once we know that there is no duplication. In other words, if "Update
profile on first login" is enabled, the user account is not yet created
when the update profile page is shown. All the info related to
BrokeredIdentityContext stuff will be available on ClientSession. This
seems to me easier and more proper solution then creating temporary
account with email in some "temporary" attribute. Temporary accounts
have other challenges (Cleaner thread for delete outdated unmerged
accounts etc).
- If "trustEmail" flag is on for IdentityProvider, the provider link
will be created automatically. (For example if Facebook user
bob(a)gmail.com authenticates for the first time and there is already
Keycloak user with email bob(a)gmail.com and trustEmail is on, the
Facebook link is automatically created for Keycloak account
bob(a)gmail.com without any additional verification)
- If "trustEmail" flag is off, there would need to be other way to
verify user before creating social link. The user will first confirm if
he wants to merge the accounts. Then there will be either:
-- Email verification: The mail will be sent to bob(a)gmail.com like
"Someone authenticates to Keycloak server http://www.keycloak.org:8080
through Facebook account bob(a)gmail.com and wants to link Facebook
account with existing Keycloak account bob(a)gmail.com . If it is you,
click here" . After user clicks, the social link is created
-- Further authentication: User will need to authenticate to existing
bob(a)gmail.com keycloak account through password (or OTP or both or
something else)
All of this is configurable through flows, so admin can disable the "Do
you want to create social link?" screen, or enforce email verification
instead of authentication, configure required authenticators etc.
- I am not sure if we want to handle just merge with existing account
during first broker login, or if we also want to handle merging of
accounts in account management? For now, I am planning to handle just
the login flow and possibly address Account management later if there is
need for it. The merging accounts in account management might be quite a
challenge as there is merge of 2 already existing user accounts with
various issues related to it (Which roles/permissions should merged
account have? Which attributes it should have? Which federation link?
etc.). But at least, I am planning to address the issue with redirect to
login forms error screen instead of stay in account management -
https://issues.jboss.org/browse/KEYCLOAK-1822
Marek
_______________________________________________
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
10:04 a.m.
On 27/10/15 14:05, Bill Burke wrote:
IMO, most applications will not care about account duplication.
Most
users won't care about account linking. So, IMO:
Remember you mentioned that
already in the previous discussions. IMO
people care and usually want to have single account on single site. If
you have 2 accounts, you never know to which of your accounts you are
authenticated. This causes various issues, like permissions available to
account1, but you are logged with account2 etc.
Remember some time ago I messed on some site and have 2 accounts like
"mposolda" and "mposolda(a)redhat.com" . I had always issues like that
when I was logged as "mposolda" I had "Access denied" when going to
page
I was supposed to have permission. So needed to logout and login again
as "mposolda(a)redhat.com" etc.
1) users should not be required to link accounts. In the case where an
account cannot be automatically linked a duplicate account should be
created
2) Providers should be trusted by default. Trusted providers can just
automatically link themselves to existing accounts that were logged in
by other trusted providers.
3) Untrusted providers can automatically link if email has been verified
for all parties.
4) Users can merge accounts that have verified emails.
5) An alternative to user self merging of account could be requiring to
enter in a temporary code after logging into each account.
#1 and #2 can be added with minimal changes to code. #3 requires a flow
on broker login and a rework of the broker SPI. #4 is account service
changes. #5 might be as easy as adding a required action.
I guess it depends if ultimate flexibility is needed. #1, #2 and #4
might be enough and require the least amount of changes and SPI refactoring.
I
think that flexibility is needed based on various JIRAs and feedback.
Just talked with Vlasta Elias from jboss.org. They have even more
requirements for possible conditions when accounts should be merged and
how to merge accounts. For example Vlasta mentioned the usecase like:
- When user logges with Facebook (or other provider) account, which is
not yet linked to any Keycloak account, then new account on Keycloak
side shouldn't be created automatically. Even if I logged with Facebook
bob(a)gmail.com and there is no KC account for email bob(a)gmail.com, there
is requirement to always show the screen like: "You just logged with
facebook account bob(a)gmail.com. Do you want to link it with existing
keycloak account?" If user agree, he would need to provide Keycloak
account he wants to merge and then verify email or re-authenticate to
link Facebook with existing account
- Another use-case was to merge account automatically based on username
from thirdparty SAML provider. For example the SAMLResponse with
username "john" returned from SAML provider, there is a need to
automatically merge it with Keycloak account "john" . In this case, they
know that "john" will be always available on Keycloak side because of
Federation provider, which SAML IDP uses as storage as well.
Based on all of this, it looks that introducing Auth SPI for first time
broker login is a way to go. This will address all of #1, #2 and #3 and
many other usecases.
For your #2, I agree that providers should be trusted by default. But
not all of providers, because some of them don't verify email. AFAIK
Facebook and Google verify email. But Github doesn't . It will be a
security hole to trust github provider by default because then user can
do something like:
- He can create github account with any email he wants like
"mposolda(a)redhat.com"
- Login with this github account into Keycloak. If we trust the email by
default, he will be logged into Keycloak to account
"mposolda(a)redhat.com", which is not his email -> FAIL
I am not sure about support for merging accounts in Account management
(like #4 and #5), will try to work on login flow first and will try to
possibly look at account management then.
Marek
On 10/27/2015 4:33 AM, Marek Posolda wrote:
> I went again through all the previous discussions, related JIRAs and
> requirements. As of now, my plan is to:
>
> - Use authentication SPI to handle the flow and related actions for
> first social login. (Update user profile, Detect duplicated account,
> Verify email or reauthenticate user if duplication is detected, Create
> social link to existing account). This allows most flexibility for
> admins to specify how exactly the linking should work
>
> - Detecting duplication will be based on email only by default - (For
> example duplication is detected if Facebook user with email
> bob(a)gmail.com authenticates, but there is already Keycloak user with
> email bob(a)gmail.com ). The people can provide their own execution if
> they want different way for detect duplications
>
> - It seems it's more proper to postpone creating user account later,
> once we know that there is no duplication. In other words, if "Update
> profile on first login" is enabled, the user account is not yet created
> when the update profile page is shown. All the info related to
> BrokeredIdentityContext stuff will be available on ClientSession. This
> seems to me easier and more proper solution then creating temporary
> account with email in some "temporary" attribute. Temporary accounts
> have other challenges (Cleaner thread for delete outdated unmerged
> accounts etc).
>
> - If "trustEmail" flag is on for IdentityProvider, the provider link
> will be created automatically. (For example if Facebook user
> bob(a)gmail.com authenticates for the first time and there is already
> Keycloak user with email bob(a)gmail.com and trustEmail is on, the
> Facebook link is automatically created for Keycloak account
> bob(a)gmail.com without any additional verification)
>
> - If "trustEmail" flag is off, there would need to be other way to
> verify user before creating social link. The user will first confirm if
> he wants to merge the accounts. Then there will be either:
> -- Email verification: The mail will be sent to bob(a)gmail.com like
> "Someone authenticates to Keycloak server http://www.keycloak.org:8080
> through Facebook account bob(a)gmail.com and wants to link Facebook
> account with existing Keycloak account bob(a)gmail.com . If it is you,
> click here" . After user clicks, the social link is created
> -- Further authentication: User will need to authenticate to existing
> bob(a)gmail.com keycloak account through password (or OTP or both or
> something else)
> All of this is configurable through flows, so admin can disable the "Do
> you want to create social link?" screen, or enforce email verification
> instead of authentication, configure required authenticators etc.
>
> - I am not sure if we want to handle just merge with existing account
> during first broker login, or if we also want to handle merging of
> accounts in account management? For now, I am planning to handle just
> the login flow and possibly address Account management later if there is
> need for it. The merging accounts in account management might be quite a
> challenge as there is merge of 2 already existing user accounts with
> various issues related to it (Which roles/permissions should merged
> account have? Which attributes it should have? Which federation link?
> etc.). But at least, I am planning to address the issue with redirect to
> login forms error screen instead of stay in account management -
> https://issues.jboss.org/browse/KEYCLOAK-1822
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
10:06 a.m.
I'm quite concerned about auto linking accounts. If someone has loads of
social networks enabled and a user has a single of those compromised (that
happens quite frequently) the attackers would then also be able to gain
access to whatever Keycloak secures. The user wouldn't even know they have
access to Keycloak, since the user has never used to compromised account to
login to Keycloak.
I strongly feel we should never link to any account without requiring user
to first authenticate to the account we are linking with.
On 27 October 2015 at 08:04, Marek Posolda <mposolda(a)redhat.com> wrote:
On 27/10/15 14:05, Bill Burke wrote:
> IMO, most applications will not care about account duplication. Most
> users won't care about account linking. So, IMO:
Remember you mentioned that already in the previous discussions. IMO
people care and usually want to have single account on single site. If
you have 2 accounts, you never know to which of your accounts you are
authenticated. This causes various issues, like permissions available to
account1, but you are logged with account2 etc.
Remember some time ago I messed on some site and have 2 accounts like
"mposolda" and "mposolda(a)redhat.com" . I had always issues like that
when I was logged as "mposolda" I had "Access denied" when going to
page
I was supposed to have permission. So needed to logout and login again
as "mposolda(a)redhat.com" etc.
>
> 1) users should not be required to link accounts. In the case where an
> account cannot be automatically linked a duplicate account should be
> created
> 2) Providers should be trusted by default. Trusted providers can just
> automatically link themselves to existing accounts that were logged in
> by other trusted providers.
> 3) Untrusted providers can automatically link if email has been verified
> for all parties.
> 4) Users can merge accounts that have verified emails.
> 5) An alternative to user self merging of account could be requiring to
> enter in a temporary code after logging into each account.
>
>
> #1 and #2 can be added with minimal changes to code. #3 requires a flow
> on broker login and a rework of the broker SPI. #4 is account service
> changes. #5 might be as easy as adding a required action.
>
> I guess it depends if ultimate flexibility is needed. #1, #2 and #4
> might be enough and require the least amount of changes and SPI
refactoring.
I think that flexibility is needed based on various JIRAs and feedback.
Just talked with Vlasta Elias from jboss.org. They have even more
requirements for possible conditions when accounts should be merged and
how to merge accounts. For example Vlasta mentioned the usecase like:
- When user logges with Facebook (or other provider) account, which is
not yet linked to any Keycloak account, then new account on Keycloak
side shouldn't be created automatically. Even if I logged with Facebook
bob(a)gmail.com and there is no KC account for email bob(a)gmail.com, there
is requirement to always show the screen like: "You just logged with
facebook account bob(a)gmail.com. Do you want to link it with existing
keycloak account?" If user agree, he would need to provide Keycloak
account he wants to merge and then verify email or re-authenticate to
link Facebook with existing account
- Another use-case was to merge account automatically based on username
from thirdparty SAML provider. For example the SAMLResponse with
username "john" returned from SAML provider, there is a need to
automatically merge it with Keycloak account "john" . In this case, they
know that "john" will be always available on Keycloak side because of
Federation provider, which SAML IDP uses as storage as well.
Based on all of this, it looks that introducing Auth SPI for first time
broker login is a way to go. This will address all of #1, #2 and #3 and
many other usecases.
For your #2, I agree that providers should be trusted by default. But
not all of providers, because some of them don't verify email. AFAIK
Facebook and Google verify email. But Github doesn't . It will be a
security hole to trust github provider by default because then user can
do something like:
- He can create github account with any email he wants like
"mposolda(a)redhat.com"
- Login with this github account into Keycloak. If we trust the email by
default, he will be logged into Keycloak to account
"mposolda(a)redhat.com", which is not his email -> FAIL
I am not sure about support for merging accounts in Account management
(like #4 and #5), will try to work on login flow first and will try to
possibly look at account management then.
Marek
>
>
> On 10/27/2015 4:33 AM, Marek Posolda wrote:
>> I went again through all the previous discussions, related JIRAs and
>> requirements. As of now, my plan is to:
>>
>> - Use authentication SPI to handle the flow and related actions for
>> first social login. (Update user profile, Detect duplicated account,
>> Verify email or reauthenticate user if duplication is detected, Create
>> social link to existing account). This allows most flexibility for
>> admins to specify how exactly the linking should work
>>
>> - Detecting duplication will be based on email only by default - (For
>> example duplication is detected if Facebook user with email
>> bob(a)gmail.com authenticates, but there is already Keycloak user with
>> email bob(a)gmail.com ). The people can provide their own execution if
>> they want different way for detect duplications
>>
>> - It seems it's more proper to postpone creating user account later,
>> once we know that there is no duplication. In other words, if "Update
>> profile on first login" is enabled, the user account is not yet created
>> when the update profile page is shown. All the info related to
>> BrokeredIdentityContext stuff will be available on ClientSession. This
>> seems to me easier and more proper solution then creating temporary
>> account with email in some "temporary" attribute. Temporary accounts
>> have other challenges (Cleaner thread for delete outdated unmerged
>> accounts etc).
>>
>> - If "trustEmail" flag is on for IdentityProvider, the provider link
>> will be created automatically. (For example if Facebook user
>> bob(a)gmail.com authenticates for the first time and there is already
>> Keycloak user with email bob(a)gmail.com and trustEmail is on, the
>> Facebook link is automatically created for Keycloak account
>> bob(a)gmail.com without any additional verification)
>>
>> - If "trustEmail" flag is off, there would need to be other way to
>> verify user before creating social link. The user will first confirm if
>> he wants to merge the accounts. Then there will be either:
>> -- Email verification: The mail will be sent to bob(a)gmail.com like
>> "Someone authenticates to Keycloak server http://www.keycloak.org:8080
>> through Facebook account bob(a)gmail.com and wants to link Facebook
>> account with existing Keycloak account bob(a)gmail.com . If it is you,
>> click here" . After user clicks, the social link is created
>> -- Further authentication: User will need to authenticate to existing
>> bob(a)gmail.com keycloak account through password (or OTP or both or
>> something else)
>> All of this is configurable through flows, so admin can disable the "Do
>> you want to create social link?" screen, or enforce email verification
>> instead of authentication, configure required authenticators etc.
>>
>> - I am not sure if we want to handle just merge with existing account
>> during first broker login, or if we also want to handle merging of
>> accounts in account management? For now, I am planning to handle just
>> the login flow and possibly address Account management later if there is
>> need for it. The merging accounts in account management might be quite a
>> challenge as there is merge of 2 already existing user accounts with
>> various issues related to it (Which roles/permissions should merged
>> account have? Which attributes it should have? Which federation link?
>> etc.). But at least, I am planning to address the issue with redirect to
>> login forms error screen instead of stay in account management -
>> https://issues.jboss.org/browse/KEYCLOAK-1822
>>
>> Marek
>> _______________________________________________
>> 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
11:34 a.m.
I agree with Stian here – the process to normalize a collection of logins requires
human-interaction nuance that should not be automated. I think Keycloak can provide a nice
user experience to aid the process, but it should always be an interactive process with
plenty of re-authentication challenges to make sure an individual still retains ownership
of the various candidate linked accounts.
From:
<keycloak-dev-bounces@lists.jboss.org<mailto:keycloak-dev-bounces@lists.jboss.org>>
on behalf of Stian Thorgersen
<sthorger@redhat.com<mailto:sthorger@redhat.com>>
Reply-To: "stian@redhat.com<mailto:stian@redhat.com>"
<stian@redhat.com<mailto:stian@redhat.com>>
Date: Wednesday, October 28, 2015 at 8:06 AM
To: Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com>>
Cc: keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>
Subject: Re: [keycloak-dev] Plan for "First login with identity brokers"
I'm quite concerned about auto linking accounts. If someone has loads of social
networks enabled and a user has a single of those compromised (that happens quite
frequently) the attackers would then also be able to gain access to whatever Keycloak
secures. The user wouldn't even know they have access to Keycloak, since the user has
never used to compromised account to login to Keycloak.
I strongly feel we should never link to any account without requiring user to first
authenticate to the account we are linking with.
On 27 October 2015 at 08:04, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
On 27/10/15 14:05, Bill Burke wrote:
IMO, most applications will not care about account duplication.
Most
users won't care about account linking. So, IMO:
Remember you mentioned that
already in the previous discussions. IMO
people care and usually want to have single account on single site. If
you have 2 accounts, you never know to which of your accounts you are
authenticated. This causes various issues, like permissions available to
account1, but you are logged with account2 etc.
Remember some time ago I messed on some site and have 2 accounts like
"mposolda" and "mposolda@redhat.com<mailto:mposolda@redhat.com>"
. I had always issues like that
when I was logged as "mposolda" I had "Access denied" when going to
page
I was supposed to have permission. So needed to logout and login again
as "mposolda@redhat.com<mailto:mposolda@redhat.com>" etc.
1) users should not be required to link accounts. In the case where an
account cannot be automatically linked a duplicate account should be
created
2) Providers should be trusted by default. Trusted providers can just
automatically link themselves to existing accounts that were logged in
by other trusted providers.
3) Untrusted providers can automatically link if email has been verified
for all parties.
4) Users can merge accounts that have verified emails.
5) An alternative to user self merging of account could be requiring to
enter in a temporary code after logging into each account.
#1 and #2 can be added with minimal changes to code. #3 requires a flow
on broker login and a rework of the broker SPI. #4 is account service
changes. #5 might be as easy as adding a required action.
I guess it depends if ultimate flexibility is needed. #1, #2 and #4
might be enough and require the least amount of changes and SPI refactoring.
I
think that flexibility is needed based on various JIRAs and feedback.
Just talked with Vlasta Elias from jboss.org<http://jboss.org>. They have even more
requirements for possible conditions when accounts should be merged and
how to merge accounts. For example Vlasta mentioned the usecase like:
- When user logges with Facebook (or other provider) account, which is
not yet linked to any Keycloak account, then new account on Keycloak
side shouldn't be created automatically. Even if I logged with Facebook
bob@gmail.com<mailto:bob@gmail.com> and there is no KC account for email
bob@gmail.com<mailto:bob@gmail.com>, there
is requirement to always show the screen like: "You just logged with
facebook account bob@gmail.com<mailto:bob@gmail.com>. Do you want to link it with
existing
keycloak account?" If user agree, he would need to provide Keycloak
account he wants to merge and then verify email or re-authenticate to
link Facebook with existing account
- Another use-case was to merge account automatically based on username
from thirdparty SAML provider. For example the SAMLResponse with
username "john" returned from SAML provider, there is a need to
automatically merge it with Keycloak account "john" . In this case, they
know that "john" will be always available on Keycloak side because of
Federation provider, which SAML IDP uses as storage as well.
Based on all of this, it looks that introducing Auth SPI for first time
broker login is a way to go. This will address all of #1, #2 and #3 and
many other usecases.
For your #2, I agree that providers should be trusted by default. But
not all of providers, because some of them don't verify email. AFAIK
Facebook and Google verify email. But Github doesn't . It will be a
security hole to trust github provider by default because then user can
do something like:
- He can create github account with any email he wants like
"mposolda@redhat.com<mailto:mposolda@redhat.com>"
- Login with this github account into Keycloak. If we trust the email by
default, he will be logged into Keycloak to account
"mposolda@redhat.com<mailto:mposolda@redhat.com>", which is not his email
-> FAIL
I am not sure about support for merging accounts in Account management
(like #4 and #5), will try to work on login flow first and will try to
possibly look at account management then.
Marek
On 10/27/2015 4:33 AM, Marek Posolda wrote:
> I went again through all the previous discussions, related JIRAs and
> requirements. As of now, my plan is to:
>
> - Use authentication SPI to handle the flow and related actions for
> first social login. (Update user profile, Detect duplicated account,
> Verify email or reauthenticate user if duplication is detected, Create
> social link to existing account). This allows most flexibility for
> admins to specify how exactly the linking should work
>
> - Detecting duplication will be based on email only by default - (For
> example duplication is detected if Facebook user with email
> bob@gmail.com<mailto:bob@gmail.com> authenticates, but there is already
Keycloak user with
> email bob@gmail.com<mailto:bob@gmail.com> ). The people can provide their own
execution if
> they want different way for detect duplications
>
> - It seems it's more proper to postpone creating user account later,
> once we know that there is no duplication. In other words, if "Update
> profile on first login" is enabled, the user account is not yet created
> when the update profile page is shown. All the info related to
> BrokeredIdentityContext stuff will be available on ClientSession. This
> seems to me easier and more proper solution then creating temporary
> account with email in some "temporary" attribute. Temporary accounts
> have other challenges (Cleaner thread for delete outdated unmerged
> accounts etc).
>
> - If "trustEmail" flag is on for IdentityProvider, the provider link
> will be created automatically. (For example if Facebook user
> bob@gmail.com<mailto:bob@gmail.com> authenticates for the first time and there
is already
> Keycloak user with email bob@gmail.com<mailto:bob@gmail.com> and trustEmail is
on, the
> Facebook link is automatically created for Keycloak account
> bob@gmail.com<mailto:bob@gmail.com> without any additional verification)
>
> - If "trustEmail" flag is off, there would need to be other way to
> verify user before creating social link. The user will first confirm if
> he wants to merge the accounts. Then there will be either:
> -- Email verification: The mail will be sent to
bob@gmail.com<mailto:bob@gmail.com> like
> "Someone authenticates to Keycloak server http://www.keycloak.org:8080
> through Facebook account bob@gmail.com<mailto:bob@gmail.com> and wants to link
Facebook
> account with existing Keycloak account bob@gmail.com<mailto:bob@gmail.com> . If
it is you,
> click here" . After user clicks, the social link is created
> -- Further authentication: User will need to authenticate to existing
> bob@gmail.com<mailto:bob@gmail.com> keycloak account through password (or OTP
or both or
> something else)
> All of this is configurable through flows, so admin can disable the "Do
> you want to create social link?" screen, or enforce email verification
> instead of authentication, configure required authenticators etc.
>
> - I am not sure if we want to handle just merge with existing account
> during first broker login, or if we also want to handle merging of
> accounts in account management? For now, I am planning to handle just
> the login flow and possibly address Account management later if there is
> need for it. The merging accounts in account management might be quite a
> challenge as there is merge of 2 already existing user accounts with
> various issues related to it (Which roles/permissions should merged
> account have? Which attributes it should have? Which federation link?
> etc.). But at least, I am planning to address the issue with redirect to
> login forms error screen instead of stay in account management -
> https://issues.jboss.org/browse/KEYCLOAK-1822
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:32 p.m.
If a user has loads of social networks and links a bunch of them, if
*any one* of them is compromised the entire account is compromised.
Most sites using social login, the only reason is there is a login is
for the appliation to collect marketing data. So, the default behavior
should make things as simple as possible for the user.
At a minimum, by default, the user should not be required to link an
account if there is a conflicting duplicate email given by the provider.
I have found develoeprs.redhat.com very difficult to use.
On 10/28/2015 12:34 PM, Scott Rehorn wrote:
I agree with Stian here – the process to normalize a collection of
logins requires human-interaction nuance that should not be automated. I
think Keycloak can provide a nice user experience to aid the process,
but it should always be an interactive process with plenty of
re-authentication challenges to make sure an individual still retains
ownership of the various candidate linked accounts.
From: <keycloak-dev-bounces(a)lists.jboss.org
<mailto:keycloak-dev-bounces@lists.jboss.org>> on behalf of Stian
Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
Reply-To: "stian(a)redhat.com <mailto:stian@redhat.com>"
<stian(a)redhat.com
<mailto:stian@redhat.com>>
Date: Wednesday, October 28, 2015 at 8:06 AM
To: Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
Subject: Re: [keycloak-dev] Plan for "First login with identity brokers"
I'm quite concerned about auto linking accounts. If someone has loads of
social networks enabled and a user has a single of those compromised
(that happens quite frequently) the attackers would then also be able to
gain access to whatever Keycloak secures. The user wouldn't even know
they have access to Keycloak, since the user has never used to
compromised account to login to Keycloak.
I strongly feel we should never link to any account without requiring
user to first authenticate to the account we are linking with.
On 27 October 2015 at 08:04, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 27/10/15 14:05, Bill Burke wrote:
> IMO, most applications will not care about account duplication. Most
> users won't care about account linking. So, IMO:
Remember you mentioned that already in the previous discussions. IMO
people care and usually want to have single account on single site. If
you have 2 accounts, you never know to which of your accounts you are
authenticated. This causes various issues, like permissions available to
account1, but you are logged with account2 etc.
Remember some time ago I messed on some site and have 2 accounts like
"mposolda" and "mposolda(a)redhat.com
<mailto:mposolda@redhat.com>" .
I had always issues like that
when I was logged as "mposolda" I had "Access denied" when going
to page
I was supposed to have permission. So needed to logout and login again
as "mposolda(a)redhat.com <mailto:mposolda@redhat.com>" etc.
>
> 1) users should not be required to link accounts. In the case where an
> account cannot be automatically linked a duplicate account should be
> created
> 2) Providers should be trusted by default. Trusted providers can just
> automatically link themselves to existing accounts that were logged in
> by other trusted providers.
> 3) Untrusted providers can automatically link if email has been verified
> for all parties.
> 4) Users can merge accounts that have verified emails.
> 5) An alternative to user self merging of account could be requiring to
> enter in a temporary code after logging into each account.
>
>
> #1 and #2 can be added with minimal changes to code. #3 requires a flow
> on broker login and a rework of the broker SPI. #4 is account service
> changes. #5 might be as easy as adding a required action.
>
> I guess it depends if ultimate flexibility is needed. #1, #2 and #4
> might be enough and require the least amount of changes and SPI refactoring.
I think that flexibility is needed based on various JIRAs and feedback.
Just talked with Vlasta Elias from jboss.org <http://jboss.org>;.
They have even more
requirements for possible conditions when accounts should be merged and
how to merge accounts. For example Vlasta mentioned the usecase like:
- When user logges with Facebook (or other provider) account, which is
not yet linked to any Keycloak account, then new account on Keycloak
side shouldn't be created automatically. Even if I logged with Facebook
bob(a)gmail.com <mailto:bob@gmail.com> and there is no KC account for
email bob(a)gmail.com <mailto:bob@gmail.com>, there
is requirement to always show the screen like: "You just logged with
facebook account bob(a)gmail.com <mailto:bob@gmail.com>. Do you want
to link it with existing
keycloak account?" If user agree, he would need to provide Keycloak
account he wants to merge and then verify email or re-authenticate to
link Facebook with existing account
- Another use-case was to merge account automatically based on username
from thirdparty SAML provider. For example the SAMLResponse with
username "john" returned from SAML provider, there is a need to
automatically merge it with Keycloak account "john" . In this case, they
know that "john" will be always available on Keycloak side because of
Federation provider, which SAML IDP uses as storage as well.
Based on all of this, it looks that introducing Auth SPI for first time
broker login is a way to go. This will address all of #1, #2 and #3 and
many other usecases.
For your #2, I agree that providers should be trusted by default. But
not all of providers, because some of them don't verify email. AFAIK
Facebook and Google verify email. But Github doesn't . It will be a
security hole to trust github provider by default because then user can
do something like:
- He can create github account with any email he wants like
"mposolda(a)redhat.com <mailto:mposolda@redhat.com>"
- Login with this github account into Keycloak. If we trust the email by
default, he will be logged into Keycloak to account
"mposolda(a)redhat.com <mailto:mposolda@redhat.com>", which is not his
email -> FAIL
I am not sure about support for merging accounts in Account management
(like #4 and #5), will try to work on login flow first and will try to
possibly look at account management then.
Marek
>
>
> On 10/27/2015 4:33 AM, Marek Posolda wrote:
>> I went again through all the previous discussions, related JIRAs and
>> requirements. As of now, my plan is to:
>>
>> - Use authentication SPI to handle the flow and related actions for
>> first social login. (Update user profile, Detect duplicated account,
>> Verify email or reauthenticate user if duplication is detected, Create
>> social link to existing account). This allows most flexibility for
>> admins to specify how exactly the linking should work
>>
>> - Detecting duplication will be based on email only by default - (For
>> example duplication is detected if Facebook user with email
>>bob(a)gmail.com <mailto:bob@gmail.com> authenticates, but there is
already Keycloak user with
>> emailbob(a)gmail.com <mailto:bob@gmail.com> ). The people can provide
their
own execution if
>> they want different way for detect duplications
>>
>> - It seems it's more proper to postpone creating user account later,
>> once we know that there is no duplication. In other words, if "Update
>> profile on first login" is enabled, the user account is not yet
created
>> when the update profile page is shown. All the info related to
>> BrokeredIdentityContext stuff will be available on ClientSession. This
>> seems to me easier and more proper solution then creating temporary
>> account with email in some "temporary" attribute. Temporary
accounts
>> have other challenges (Cleaner thread for delete outdated unmerged
>> accounts etc).
>>
>> - If "trustEmail" flag is on for IdentityProvider, the provider
link
>> will be created automatically. (For example if Facebook user
>>bob(a)gmail.com <mailto:bob@gmail.com> authenticates for the first
time and there is already
>> Keycloak user with emailbob(a)gmail.com <mailto:bob@gmail.com> and
trustEmail is on, the
>> Facebook link is automatically created for Keycloak account
>>bob(a)gmail.com <mailto:bob@gmail.com> without any additional
verification)
>>
>> - If "trustEmail" flag is off, there would need to be other way
to
>> verify user before creating social link. The user will first confirm if
>> he wants to merge the accounts. Then there will be either:
>> -- Email verification: The mail will be sent tobob(a)gmail.com
<mailto:bob@gmail.com> like
>> "Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080
>> through Facebook accountbob(a)gmail.com <mailto:bob@gmail.com> and wants
to link Facebook
>> account with existing Keycloak accountbob(a)gmail.com
<mailto:bob@gmail.com> . If it is you,
>> click here" . After user clicks, the social link is created
>> -- Further authentication: User will need to authenticate to existing
>>bob(a)gmail.com <mailto:bob@gmail.com> keycloak account through
password (or OTP or both or
>> something else)
>> All of this is configurable through flows, so admin can disable the
"Do
>> you want to create social link?" screen, or enforce email verification
>> instead of authentication, configure required authenticators etc.
>>
>> - I am not sure if we want to handle just merge with existing account
>> during first broker login, or if we also want to handle merging of
>> accounts in account management? For now, I am planning to handle just
>> the login flow and possibly address Account management later if there is
>> need for it. The merging accounts in account management might be quite a
>> challenge as there is merge of 2 already existing user accounts with
>> various issues related to it (Which roles/permissions should merged
>> account have? Which attributes it should have? Which federation link?
>> etc.). But at least, I am planning to address the issue with redirect to
>> login forms error screen instead of stay in account management -
>>https://issues.jboss.org/browse/KEYCLOAK-1822
>>
>> Marek
>> _______________________________________________
>> 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
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:44 p.m.
It’s important to allow for account linking without a manual step if the trust email is
true. I’m not against optionally forcing the user to link accounts. However, if the user
never confirms they want to link, I’d want to identity broker account to never be
created.
Hope that makes sense. I know there are a lot of use cases you’re considering here but I’d
rather not have to write code to maintain automatic account linking (with or without a
verification step).
Also, if user me(a)gmail.com is registered in Keycloak and then uses Google+ authentication,
it would be silly to make the user confirm they want the accounts linked.
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
<http://www.sigstr.com/>
On Oct 28, 2015, at 4:32 PM, Bill Burke <bburke(a)redhat.com>
wrote:
If a user has loads of social networks and links a bunch of them, if
*any one* of them is compromised the entire account is compromised.
Most sites using social login, the only reason is there is a login is
for the appliation to collect marketing data. So, the default behavior
should make things as simple as possible for the user.
At a minimum, by default, the user should not be required to link an
account if there is a conflicting duplicate email given by the provider.
I have found develoeprs.redhat.com very difficult to use.
On 10/28/2015 12:34 PM, Scott Rehorn wrote:
> I agree with Stian here – the process to normalize a collection of
> logins requires human-interaction nuance that should not be automated. I
> think Keycloak can provide a nice user experience to aid the process,
> but it should always be an interactive process with plenty of
> re-authentication challenges to make sure an individual still retains
> ownership of the various candidate linked accounts.
>
> From: <keycloak-dev-bounces(a)lists.jboss.org
> <mailto:keycloak-dev-bounces@lists.jboss.org>> on behalf of Stian
> Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
> Reply-To: "stian(a)redhat.com <mailto:stian@redhat.com>"
<stian(a)redhat.com
> <mailto:stian@redhat.com>>
> Date: Wednesday, October 28, 2015 at 8:06 AM
> To: Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>>
> Subject: Re: [keycloak-dev] Plan for "First login with identity brokers"
>
> I'm quite concerned about auto linking accounts. If someone has loads of
> social networks enabled and a user has a single of those compromised
> (that happens quite frequently) the attackers would then also be able to
> gain access to whatever Keycloak secures. The user wouldn't even know
> they have access to Keycloak, since the user has never used to
> compromised account to login to Keycloak.
>
> I strongly feel we should never link to any account without requiring
> user to first authenticate to the account we are linking with.
>
> On 27 October 2015 at 08:04, Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> On 27/10/15 14:05, Bill Burke wrote:
>> IMO, most applications will not care about account duplication. Most
>> users won't care about account linking. So, IMO:
> Remember you mentioned that already in the previous discussions. IMO
> people care and usually want to have single account on single site. If
> you have 2 accounts, you never know to which of your accounts you are
> authenticated. This causes various issues, like permissions available to
> account1, but you are logged with account2 etc.
>
> Remember some time ago I messed on some site and have 2 accounts like
> "mposolda" and "mposolda(a)redhat.com
<mailto:mposolda@redhat.com>" .
> I had always issues like that
> when I was logged as "mposolda" I had "Access denied" when
going to page
> I was supposed to have permission. So needed to logout and login again
> as "mposolda(a)redhat.com <mailto:mposolda@redhat.com>" etc.
>>
>> 1) users should not be required to link accounts. In the case where an
>> account cannot be automatically linked a duplicate account should be
>> created
>> 2) Providers should be trusted by default. Trusted providers can just
>> automatically link themselves to existing accounts that were logged in
>> by other trusted providers.
>> 3) Untrusted providers can automatically link if email has been verified
>> for all parties.
>> 4) Users can merge accounts that have verified emails.
>> 5) An alternative to user self merging of account could be requiring to
>> enter in a temporary code after logging into each account.
>>
>>
>> #1 and #2 can be added with minimal changes to code. #3 requires a flow
>> on broker login and a rework of the broker SPI. #4 is account service
>> changes. #5 might be as easy as adding a required action.
>>
>> I guess it depends if ultimate flexibility is needed. #1, #2 and #4
>> might be enough and require the least amount of changes and SPI refactoring.
> I think that flexibility is needed based on various JIRAs and feedback.
> Just talked with Vlasta Elias from jboss.org <http://jboss.org>;.
> They have even more
> requirements for possible conditions when accounts should be merged and
> how to merge accounts. For example Vlasta mentioned the usecase like:
> - When user logges with Facebook (or other provider) account, which is
> not yet linked to any Keycloak account, then new account on Keycloak
> side shouldn't be created automatically. Even if I logged with Facebook
> bob(a)gmail.com <mailto:bob@gmail.com> and there is no KC account for
> email bob(a)gmail.com <mailto:bob@gmail.com>, there
> is requirement to always show the screen like: "You just logged with
> facebook account bob(a)gmail.com <mailto:bob@gmail.com>. Do you want
> to link it with existing
> keycloak account?" If user agree, he would need to provide Keycloak
> account he wants to merge and then verify email or re-authenticate to
> link Facebook with existing account
>
> - Another use-case was to merge account automatically based on username
> from thirdparty SAML provider. For example the SAMLResponse with
> username "john" returned from SAML provider, there is a need to
> automatically merge it with Keycloak account "john" . In this case,
they
> know that "john" will be always available on Keycloak side because of
> Federation provider, which SAML IDP uses as storage as well.
>
> Based on all of this, it looks that introducing Auth SPI for first time
> broker login is a way to go. This will address all of #1, #2 and #3 and
> many other usecases.
>
> For your #2, I agree that providers should be trusted by default. But
> not all of providers, because some of them don't verify email. AFAIK
> Facebook and Google verify email. But Github doesn't . It will be a
> security hole to trust github provider by default because then user can
> do something like:
> - He can create github account with any email he wants like
> "mposolda(a)redhat.com <mailto:mposolda@redhat.com>"
> - Login with this github account into Keycloak. If we trust the email by
> default, he will be logged into Keycloak to account
> "mposolda(a)redhat.com <mailto:mposolda@redhat.com>", which is not
his
> email -> FAIL
>
> I am not sure about support for merging accounts in Account management
> (like #4 and #5), will try to work on login flow first and will try to
> possibly look at account management then.
>
> Marek
>>
>>
>> On 10/27/2015 4:33 AM, Marek Posolda wrote:
>>> I went again through all the previous discussions, related JIRAs and
>>> requirements. As of now, my plan is to:
>>>
>>> - Use authentication SPI to handle the flow and related actions for
>>> first social login. (Update user profile, Detect duplicated account,
>>> Verify email or reauthenticate user if duplication is detected, Create
>>> social link to existing account). This allows most flexibility for
>>> admins to specify how exactly the linking should work
>>>
>>> - Detecting duplication will be based on email only by default - (For
>>> example duplication is detected if Facebook user with email
>>> bob(a)gmail.com <mailto:bob@gmail.com> authenticates, but there is
> already Keycloak user with
>>> emailbob(a)gmail.com <mailto:bob@gmail.com> ). The people can provide
their
> own execution if
>>> they want different way for detect duplications
>>>
>>> - It seems it's more proper to postpone creating user account later,
>>> once we know that there is no duplication. In other words, if "Update
>>> profile on first login" is enabled, the user account is not yet created
>>> when the update profile page is shown. All the info related to
>>> BrokeredIdentityContext stuff will be available on ClientSession. This
>>> seems to me easier and more proper solution then creating temporary
>>> account with email in some "temporary" attribute. Temporary
accounts
>>> have other challenges (Cleaner thread for delete outdated unmerged
>>> accounts etc).
>>>
>>> - If "trustEmail" flag is on for IdentityProvider, the provider
link
>>> will be created automatically. (For example if Facebook user
>>> bob(a)gmail.com <mailto:bob@gmail.com> authenticates for the first
> time and there is already
>>> Keycloak user with emailbob(a)gmail.com <mailto:bob@gmail.com> and
trustEmail is on, the
>>> Facebook link is automatically created for Keycloak account
>>> bob(a)gmail.com <mailto:bob@gmail.com> without any additional
> verification)
>>>
>>> - If "trustEmail" flag is off, there would need to be other way to
>>> verify user before creating social link. The user will first confirm if
>>> he wants to merge the accounts. Then there will be either:
>>> -- Email verification: The mail will be sent tobob(a)gmail.com
<mailto:bob@gmail.com> like
>>> "Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080
>>> through Facebook accountbob(a)gmail.com <mailto:bob@gmail.com> and wants
to link Facebook
>>> account with existing Keycloak accountbob(a)gmail.com
<mailto:bob@gmail.com> . If it is you,
>>> click here" . After user clicks, the social link is created
>>> -- Further authentication: User will need to authenticate to existing
>>> bob(a)gmail.com <mailto:bob@gmail.com> keycloak account through
> password (or OTP or both or
>>> something else)
>>> All of this is configurable through flows, so admin can disable the "Do
>>> you want to create social link?" screen, or enforce email verification
>>> instead of authentication, configure required authenticators etc.
>>>
>>> - I am not sure if we want to handle just merge with existing account
>>> during first broker login, or if we also want to handle merging of
>>> accounts in account management? For now, I am planning to handle just
>>> the login flow and possibly address Account management later if there is
>>> need for it. The merging accounts in account management might be quite a
>>> challenge as there is merge of 2 already existing user accounts with
>>> various issues related to it (Which roles/permissions should merged
>>> account have? Which attributes it should have? Which federation link?
>>> etc.). But at least, I am planning to address the issue with redirect to
>>> login forms error screen instead of stay in account management -
>>> https://issues.jboss.org/browse/KEYCLOAK-1822
>>>
>>> Marek
>>> _______________________________________________
>>> 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
> 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
3:05 a.m.
On 28/10/15 23:44, Scott Rossillo wrote:
It’s important to allow for account linking without a manual step if
the trust email is true. I’m not against optionally forcing the user
to link accounts. However, if the user never confirms they want to
link, I’d want to identity broker account to never be created.
Hope that makes sense. I know there are a lot of use cases you’re
considering here but I’d rather not have to write code to maintain
automatic account linking (with or without a verification step)
Also, if user me(a)gmail.com <mailto:me@gmail.com> is registered in
Keycloak and then uses Google+ authentication, it would be silly to
make the user confirm they want the accounts linked.
With the authentication flows, it's possible to do things very flexible.
However the question is what should be the default behaviour. I think we
will have the possibility to "autolink" without additional
verification/reauthentication, but it won't be likely enabled by
default. As Stian mentioned, there is some security impact with
autolinking even for trusted providers like Google.
Marek
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com <mailto:srossillo@smartling.com>
Powered by Sigstr <http://www.sigstr.com/>
> On Oct 28, 2015, at 4:32 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> If a user has loads of social networks and links a bunch of them, if
> *any one* of them is compromised the entire account is compromised.
> Most sites using social login, the only reason is there is a login is
> for the appliation to collect marketing data. So, the default behavior
> should make things as simple as possible for the user.
>
> At a minimum, by default, the user should not be required to link an
> account if there is a conflicting duplicate email given by the provider.
> I have found develoeprs.redhat.com <http://develoeprs.redhat.com>
> very difficult to use.
>
>
>
> On 10/28/2015 12:34 PM, Scott Rehorn wrote:
>> I agree with Stian here – the process to normalize a collection of
>> logins requires human-interaction nuance that should not be automated. I
>> think Keycloak can provide a nice user experience to aid the process,
>> but it should always be an interactive process with plenty of
>> re-authentication challenges to make sure an individual still retains
>> ownership of the various candidate linked accounts.
>>
>> From: <keycloak-dev-bounces(a)lists.jboss.org
>> <mailto:keycloak-dev-bounces@lists.jboss.org>
>> <mailto:keycloak-dev-bounces@lists.jboss.org>> on behalf of Stian
>> Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>
>> <mailto:sthorger@redhat.com>>
>> Reply-To: "stian(a)redhat.com <mailto:stian@redhat.com>
>> <mailto:stian@redhat.com>" <stian(a)redhat.com
<mailto:stian@redhat.com>
>> <mailto:stian@redhat.com>>
>> Date: Wednesday, October 28, 2015 at 8:06 AM
>> To: Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>
>> <mailto:mposolda@redhat.com>>
>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>> <mailto:keycloak-dev@lists.jboss.org>>
>> Subject: Re: [keycloak-dev] Plan for "First login with identity
brokers"
>>
>> I'm quite concerned about auto linking accounts. If someone has loads of
>> social networks enabled and a user has a single of those compromised
>> (that happens quite frequently) the attackers would then also be able to
>> gain access to whatever Keycloak secures. The user wouldn't even know
>> they have access to Keycloak, since the user has never used to
>> compromised account to login to Keycloak.
>>
>> I strongly feel we should never link to any account without requiring
>> user to first authenticate to the account we are linking with.
>>
>> On 27 October 2015 at 08:04, Marek Posolda <mposolda(a)redhat.com
>> <mailto:mposolda@redhat.com>
>> <mailto:mposolda@redhat.com>> wrote:
>>
>> On 27/10/15 14:05, Bill Burke wrote:
>>> IMO, most applications will not care about account duplication. Most
>>> users won't care about account linking. So, IMO:
>> Remember you mentioned that already in the previous discussions. IMO
>> people care and usually want to have single account on single
>> site. If
>> you have 2 accounts, you never know to which of your accounts you are
>> authenticated. This causes various issues, like permissions
>> available to
>> account1, but you are logged with account2 etc.
>>
>> Remember some time ago I messed on some site and have 2 accounts like
>> "mposolda" and "mposolda(a)redhat.com
<mailto:mposolda@redhat.com>
>> <mailto:mposolda@redhat.com>" .
>> I had always issues like that
>> when I was logged as "mposolda" I had "Access denied" when
going
>> to page
>> I was supposed to have permission. So needed to logout and login
>> again
>> as "mposolda(a)redhat.com <mailto:mposolda@redhat.com>
>> <mailto:mposolda@redhat.com>" etc.
>>>
>>> 1) users should not be required to link accounts. In the case where an
>>> account cannot be automatically linked a duplicate account should be
>>> created
>>> 2) Providers should be trusted by default. Trusted providers can just
>>> automatically link themselves to existing accounts that were logged in
>>> by other trusted providers.
>>> 3) Untrusted providers can automatically link if email has been
>>> verified
>>> for all parties.
>>> 4) Users can merge accounts that have verified emails.
>>> 5) An alternative to user self merging of account could be requiring to
>>> enter in a temporary code after logging into each account.
>>>
>>>
>>> #1 and #2 can be added with minimal changes to code. #3 requires a
>>> flow
>>> on broker login and a rework of the broker SPI. #4 is account service
>>> changes. #5 might be as easy as adding a required action.
>>>
>>> I guess it depends if ultimate flexibility is needed. #1, #2 and #4
>>> might be enough and require the least amount of changes and SPI
>>> refactoring.
>> I think that flexibility is needed based on various JIRAs and
>> feedback.
>> Just talked with Vlasta Elias from jboss.org <http://jboss.org>
>> <http://jboss.org>;.
>> They have even more
>> requirements for possible conditions when accounts should be
>> merged and
>> how to merge accounts. For example Vlasta mentioned the usecase like:
>> - When user logges with Facebook (or other provider) account,
>> which is
>> not yet linked to any Keycloak account, then new account on Keycloak
>> side shouldn't be created automatically. Even if I logged with
>> Facebook
>> bob(a)gmail.com <mailto:bob@gmail.com> <mailto:bob@gmail.com> and
>> there is no KC account for
>> email bob(a)gmail.com <mailto:bob@gmail.com>
>> <mailto:bob@gmail.com>, there
>> is requirement to always show the screen like: "You just logged with
>> facebook account bob(a)gmail.com <mailto:bob@gmail.com>
>> <mailto:bob@gmail.com>. Do you want
>> to link it with existing
>> keycloak account?" If user agree, he would need to provide Keycloak
>> account he wants to merge and then verify email or re-authenticate to
>> link Facebook with existing account
>>
>> - Another use-case was to merge account automatically based on
>> username
>> from thirdparty SAML provider. For example the SAMLResponse with
>> username "john" returned from SAML provider, there is a need to
>> automatically merge it with Keycloak account "john" . In this
>> case, they
>> know that "john" will be always available on Keycloak side because
of
>> Federation provider, which SAML IDP uses as storage as well.
>>
>> Based on all of this, it looks that introducing Auth SPI for
>> first time
>> broker login is a way to go. This will address all of #1, #2 and
>> #3 and
>> many other usecases.
>>
>> For your #2, I agree that providers should be trusted by default. But
>> not all of providers, because some of them don't verify email. AFAIK
>> Facebook and Google verify email. But Github doesn't . It will be a
>> security hole to trust github provider by default because then
>> user can
>> do something like:
>> - He can create github account with any email he wants like
>> "mposolda(a)redhat.com <mailto:mposolda@redhat.com>
>> <mailto:mposolda@redhat.com>"
>> - Login with this github account into Keycloak. If we trust the
>> email by
>> default, he will be logged into Keycloak to account
>> "mposolda(a)redhat.com <mailto:mposolda@redhat.com>
>> <mailto:mposolda@redhat.com>", which is not his
>> email -> FAIL
>>
>> I am not sure about support for merging accounts in Account
>> management
>> (like #4 and #5), will try to work on login flow first and will
>> try to
>> possibly look at account management then.
>>
>> Marek
>>>
>>>
>>> On 10/27/2015 4:33 AM, Marek Posolda wrote:
>>>> I went again through all the previous discussions, related JIRAs and
>>>> requirements. As of now, my plan is to:
>>>>
>>>> - Use authentication SPI to handle the flow and related actions for
>>>> first social login. (Update user profile, Detect duplicated account,
>>>> Verify email or reauthenticate user if duplication is detected, Create
>>>> social link to existing account). This allows most flexibility for
>>>> admins to specify how exactly the linking should work
>>>>
>>>> - Detecting duplication will be based on email only by default - (For
>>>> example duplication is detected if Facebook user with email
>>>> bob(a)gmail.com <mailto:bob@gmail.com> <mailto:bob@gmail.com>
>>>> authenticates, but there is
>> already Keycloak user with
>>>> emailbob(a)gmail.com <mailto:emailbob@gmail.com>
>>>> <mailto:bob@gmail.com> ). The people can provide their
>> own execution if
>>>> they want different way for detect duplications
>>>>
>>>> - It seems it's more proper to postpone creating user account later,
>>>> once we know that there is no duplication. In other words, if
"Update
>>>> profile on first login" is enabled, the user account is not yet
>>>> created
>>>> when the update profile page is shown. All the info related to
>>>> BrokeredIdentityContext stuff will be available on ClientSession. This
>>>> seems to me easier and more proper solution then creating temporary
>>>> account with email in some "temporary" attribute. Temporary
accounts
>>>> have other challenges (Cleaner thread for delete outdated unmerged
>>>> accounts etc).
>>>>
>>>> - If "trustEmail" flag is on for IdentityProvider, the provider
link
>>>> will be created automatically. (For example if Facebook user
>>>> bob(a)gmail.com <mailto:bob@gmail.com> <mailto:bob@gmail.com>
>>>> authenticates for the first
>> time and there is already
>>>> Keycloak user with emailbob(a)gmail.com <mailto:emailbob@gmail.com>
>>>> <mailto:bob@gmail.com> and trustEmail is on, the
>>>> Facebook link is automatically created for Keycloak account
>>>> bob(a)gmail.com <mailto:bob@gmail.com> <mailto:bob@gmail.com>
>>>> without any additional
>> verification)
>>>>
>>>> - If "trustEmail" flag is off, there would need to be other way
to
>>>> verify user before creating social link. The user will first
>>>> confirm if
>>>> he wants to merge the accounts. Then there will be either:
>>>> -- Email verification: The mail will be sent tobob(a)gmail.com
>>>> <mailto:tobob@gmail.com> <mailto:bob@gmail.com> like
>>>> "Someone authenticates to Keycloak
serverhttp://www.keycloak.org:8080
>>>> through Facebook accountbob(a)gmail.com
>>>> <mailto:accountbob@gmail.com> <mailto:bob@gmail.com> and
wants to
>>>> link Facebook
>>>> account with existing Keycloak accountbob(a)gmail.com
>>>> <mailto:accountbob@gmail.com> <mailto:bob@gmail.com> . If it
is you,
>>>> click here" . After user clicks, the social link is created
>>>> -- Further authentication: User will need to authenticate to existing
>>>> bob(a)gmail.com <mailto:bob@gmail.com> <mailto:bob@gmail.com>
>>>> keycloak account through
>> password (or OTP or both or
>>>>
realms/rhd/login-actions/email-verification?code=KYxAcXLs140rGN8CwQFtQssOj2es7aZBa6DrbbdGHng.822f5fb1-e05b-4e17-bb90-e6bbb8fba68esomething
>>>> else)
>>>> All of this is configurable through flows, so admin can disable
>>>> the "Do
>>>> you want to create social link?" screen, or enforce email
verification
>>>> instead of authentication, configure required authenticators etc.
>>>>
>>>> - I am not sure if we want to handle just merge with existing account
>>>> during first broker login, or if we also want to handle merging of
>>>> accounts in account management? For now, I am planning to handle just
>>>> the login flow and possibly address Account management later if
>>>> there is
>>>> need for it. The merging accounts in account management might be
>>>> quite a
>>>> challenge as there is merge of 2 already existing user accounts with
>>>> various issues related to it (Which roles/permissions should merged
>>>> account have? Which attributes it should have? Which federation link?
>>>> etc.). But at least, I am planning to address the issue with
>>>> redirect to
>>>> login forms error screen instead of stay in account management -
>>>> https://issues.jboss.org/browse/KEYCLOAK-1822
>>>>
>>>> Marek
>>>> _______________________________________________
>>>> 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>
>> <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
> 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
4:44 a.m.
On 29.10.2015 09:05, Marek Posolda wrote:
On 28/10/15 23:44, Scott Rossillo wrote:
> It’s important to allow for account linking without a manual step if
> the trust email is true. I’m not against optionally forcing the user
> to link accounts. However, if the user never confirms they want to
> link, I’d want to identity broker account to never be created.
>
> Hope that makes sense. I know there are a lot of use cases you’re
> considering here but I’d rather not have to write code to maintain
> automatic account linking (with or without a verification step)
>
> Also, if user me(a)gmail.com <mailto:me@gmail.com> is registered in
> Keycloak and then uses Google+ authentication, it would be silly to
> make the user confirm they want the accounts linked.
With the authentication flows, it's possible to do things very
flexible. However the question is what should be the default
behaviour. I think we will have the possibility to "autolink" without
additional verification/reauthentication, but it won't be likely
enabled by default. As Stian mentioned, there is some security impact
with autolinking even for trusted providers like Google.
+1000 for flexibility but sane and secure defaults.
Vl
Marek
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo(a)smartling.com <mailto:srossillo@smartling.com>
>
> Powered by Sigstr <http://www.sigstr.com/>
>
>> On Oct 28, 2015, at 4:32 PM, Bill Burke <bburke(a)redhat.com> wrote:
>>
>> If a user has loads of social networks and links a bunch of them, if
>> *any one* of them is compromised the entire account is compromised.
>> Most sites using social login, the only reason is there is a login is
>> for the appliation to collect marketing data. So, the default behavior
>> should make things as simple as possible for the user.
>>
>> At a minimum, by default, the user should not be required to link an
>> account if there is a conflicting duplicate email given by the
>> provider.
>> I have found develoeprs.redhat.com <http://develoeprs.redhat.com>
>> very difficult to use.
>>
>>
>>
>> On 10/28/2015 12:34 PM, Scott Rehorn wrote:
>>> I agree with Stian here – the process to normalize a collection of
>>> logins requires human-interaction nuance that should not be
>>> automated. I
>>> think Keycloak can provide a nice user experience to aid the process,
>>> but it should always be an interactive process with plenty of
>>> re-authentication challenges to make sure an individual still retains
>>> ownership of the various candidate linked accounts.
>>>
>>> From: <keycloak-dev-bounces(a)lists.jboss.org
>>> <mailto:keycloak-dev-bounces@lists.jboss.org>
>>> <mailto:keycloak-dev-bounces@lists.jboss.org>> on behalf of Stian
>>> Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>
>>> <mailto:sthorger@redhat.com>>
>>> Reply-To: "stian(a)redhat.com <mailto:stian@redhat.com>
>>> <mailto:stian@redhat.com>" <stian(a)redhat.com
<mailto:stian@redhat.com>
>>> <mailto:stian@redhat.com>>
>>> Date: Wednesday, October 28, 2015 at 8:06 AM
>>> To: Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>
>>> <mailto:mposolda@redhat.com>>
>>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org
>>> <mailto:keycloak-dev@lists.jboss.org>
>>> <mailto:keycloak-dev@lists.jboss.org>>
>>> Subject: Re: [keycloak-dev] Plan for "First login with identity
>>> brokers"
>>>
>>> I'm quite concerned about auto linking accounts. If someone has
>>> loads of
>>> social networks enabled and a user has a single of those compromised
>>> (that happens quite frequently) the attackers would then also be
>>> able to
>>> gain access to whatever Keycloak secures. The user wouldn't even know
>>> they have access to Keycloak, since the user has never used to
>>> compromised account to login to Keycloak.
>>>
>>> I strongly feel we should never link to any account without requiring
>>> user to first authenticate to the account we are linking with.
>>>
>>> On 27 October 2015 at 08:04, Marek Posolda <mposolda(a)redhat.com
>>> <mailto:mposolda@redhat.com>> wrote:
>>>
>>> On 27/10/15 14:05, Bill Burke wrote:
>>>> IMO, most applications will not care about account duplication. Most
>>>> users won't care about account linking. So, IMO:
>>> Remember you mentioned that already in the previous discussions. IMO
>>> people care and usually want to have single account on single
>>> site. If
>>> you have 2 accounts, you never know to which of your accounts
>>> you are
>>> authenticated. This causes various issues, like permissions
>>> available to
>>> account1, but you are logged with account2 etc.
>>>
>>> Remember some time ago I messed on some site and have 2 accounts
>>> like
>>> "mposolda" and "mposolda(a)redhat.com
<mailto:mposolda@redhat.com>
>>> <mailto:mposolda@redhat.com>" .
>>> I had always issues like that
>>> when I was logged as "mposolda" I had "Access denied"
when going
>>> to page
>>> I was supposed to have permission. So needed to logout and login
>>> again
>>> as "mposolda(a)redhat.com <mailto:mposolda@redhat.com>
>>> <mailto:mposolda@redhat.com>" etc.
>>>>
>>>> 1) users should not be required to link accounts. In the case
>>>> where an
>>>> account cannot be automatically linked a duplicate account should be
>>>> created
>>>> 2) Providers should be trusted by default. Trusted providers can just
>>>> automatically link themselves to existing accounts that were logged in
>>>> by other trusted providers.
>>>> 3) Untrusted providers can automatically link if email has been
>>>> verified
>>>> for all parties.
>>>> 4) Users can merge accounts that have verified emails.
>>>> 5) An alternative to user self merging of account could be
>>>> requiring to
>>>> enter in a temporary code after logging into each account.
>>>>
>>>>
>>>> #1 and #2 can be added with minimal changes to code. #3 requires
>>>> a flow
>>>> on broker login and a rework of the broker SPI. #4 is account service
>>>> changes. #5 might be as easy as adding a required action.
>>>>
>>>> I guess it depends if ultimate flexibility is needed. #1, #2 and #4
>>>> might be enough and require the least amount of changes and SPI
>>>> refactoring.
>>> I think that flexibility is needed based on various JIRAs and
>>> feedback.
>>> Just talked with Vlasta Elias from jboss.org <http://jboss.org>
>>> <http://jboss.org>;.
>>> They have even more
>>> requirements for possible conditions when accounts should be
>>> merged and
>>> how to merge accounts. For example Vlasta mentioned the usecase
>>> like:
>>> - When user logges with Facebook (or other provider) account,
>>> which is
>>> not yet linked to any Keycloak account, then new account on Keycloak
>>> side shouldn't be created automatically. Even if I logged with
>>> Facebook
>>> bob(a)gmail.com <mailto:bob@gmail.com> <mailto:bob@gmail.com>
and
>>> there is no KC account for
>>> email bob(a)gmail.com <mailto:bob@gmail.com>
>>> <mailto:bob@gmail.com>, there
>>> is requirement to always show the screen like: "You just logged with
>>> facebook account bob(a)gmail.com <mailto:bob@gmail.com>
>>> <mailto:bob@gmail.com>. Do you want
>>> to link it with existing
>>> keycloak account?" If user agree, he would need to provide Keycloak
>>> account he wants to merge and then verify email or
>>> re-authenticate to
>>> link Facebook with existing account
>>>
>>> - Another use-case was to merge account automatically based on
>>> username
>>> from thirdparty SAML provider. For example the SAMLResponse with
>>> username "john" returned from SAML provider, there is a need to
>>> automatically merge it with Keycloak account "john" . In this
>>> case, they
>>> know that "john" will be always available on Keycloak side
>>> because of
>>> Federation provider, which SAML IDP uses as storage as well.
>>>
>>> Based on all of this, it looks that introducing Auth SPI for
>>> first time
>>> broker login is a way to go. This will address all of #1, #2 and
>>> #3 and
>>> many other usecases.
>>>
>>> For your #2, I agree that providers should be trusted by
>>> default. But
>>> not all of providers, because some of them don't verify email. AFAIK
>>> Facebook and Google verify email. But Github doesn't . It will be a
>>> security hole to trust github provider by default because then
>>> user can
>>> do something like:
>>> - He can create github account with any email he wants like
>>> "mposolda(a)redhat.com <mailto:mposolda@redhat.com>
>>> <mailto:mposolda@redhat.com>"
>>> - Login with this github account into Keycloak. If we trust the
>>> email by
>>> default, he will be logged into Keycloak to account
>>> "mposolda(a)redhat.com <mailto:mposolda@redhat.com>
>>> <mailto:mposolda@redhat.com>", which is not his
>>> email -> FAIL
>>>
>>> I am not sure about support for merging accounts in Account
>>> management
>>> (like #4 and #5), will try to work on login flow first and will
>>> try to
>>> possibly look at account management then.
>>>
>>> Marek
>>>>
>>>>
>>>> On 10/27/2015 4:33 AM, Marek Posolda wrote:
>>>>> I went again through all the previous discussions, related JIRAs and
>>>>> requirements. As of now, my plan is to:
>>>>>
>>>>> - Use authentication SPI to handle the flow and related actions for
>>>>> first social login. (Update user profile, Detect duplicated account,
>>>>> Verify email or reauthenticate user if duplication is detected,
>>>>> Create
>>>>> social link to existing account). This allows most flexibility for
>>>>> admins to specify how exactly the linking should work
>>>>>
>>>>> - Detecting duplication will be based on email only by default -
(For
>>>>> example duplication is detected if Facebook user with email
>>>>> bob(a)gmail.com <mailto:bob@gmail.com>
<mailto:bob@gmail.com>
>>>>> authenticates, but there is
>>> already Keycloak user with
>>>>> emailbob(a)gmail.com <mailto:bob@gmail.com> ). The people can
>>>>> provide their
>>> own execution if
>>>>> they want different way for detect duplications
>>>>>
>>>>> - It seems it's more proper to postpone creating user account
later,
>>>>> once we know that there is no duplication. In other words, if
"Update
>>>>> profile on first login" is enabled, the user account is not yet
>>>>> created
>>>>> when the update profile page is shown. All the info related to
>>>>> BrokeredIdentityContext stuff will be available on ClientSession.
>>>>> This
>>>>> seems to me easier and more proper solution then creating temporary
>>>>> account with email in some "temporary" attribute. Temporary
accounts
>>>>> have other challenges (Cleaner thread for delete outdated unmerged
>>>>> accounts etc).
>>>>>
>>>>> - If "trustEmail" flag is on for IdentityProvider, the
provider link
>>>>> will be created automatically. (For example if Facebook user
>>>>> bob(a)gmail.com <mailto:bob@gmail.com>
<mailto:bob@gmail.com>
>>>>> authenticates for the first
>>> time and there is already
>>>>> Keycloak user with emailbob(a)gmail.com
<mailto:emailbob@gmail.com>
>>>>> <mailto:bob@gmail.com> and trustEmail is on, the
>>>>> Facebook link is automatically created for Keycloak account
>>>>> bob(a)gmail.com <mailto:bob@gmail.com>
<mailto:bob@gmail.com>
>>>>> without any additional
>>> verification)
>>>>>
>>>>> - If "trustEmail" flag is off, there would need to be other
way to
>>>>> verify user before creating social link. The user will first
>>>>> confirm if
>>>>> he wants to merge the accounts. Then there will be either:
>>>>> -- Email verification: The mail will be sent tobob(a)gmail.com
>>>>> <mailto:bob@gmail.com> like
>>>>> "Someone authenticates to Keycloak
serverhttp://www.keycloak.org:8080
>>>>> through Facebook accountbob(a)gmail.com
>>>>> <mailto:accountbob@gmail.com> <mailto:bob@gmail.com> and
wants to
>>>>> link Facebook
>>>>> account with existing Keycloak accountbob(a)gmail.com
>>>>> <mailto:bob@gmail.com> . If it is you,
>>>>> click here" . After user clicks, the social link is created
>>>>> -- Further authentication: User will need to authenticate to
existing
>>>>> bob(a)gmail.com <mailto:bob@gmail.com>
<mailto:bob@gmail.com>
>>>>> keycloak account through
>>> password (or OTP or both or
>>>>>
realms/rhd/login-actions/email-verification?code=KYxAcXLs140rGN8CwQFtQssOj2es7aZBa6DrbbdGHng.822f5fb1-e05b-4e17-bb90-e6bbb8fba68esomething
>>>>> else)
>>>>> All of this is configurable through flows, so admin can disable
>>>>> the "Do
>>>>> you want to create social link?" screen, or enforce email
>>>>> verification
>>>>> instead of authentication, configure required authenticators etc.
>>>>>
>>>>> - I am not sure if we want to handle just merge with existing
account
>>>>> during first broker login, or if we also want to handle merging of
>>>>> accounts in account management? For now, I am planning to handle
just
>>>>> the login flow and possibly address Account management later if
>>>>> there is
>>>>> need for it. The merging accounts in account management might be
>>>>> quite a
>>>>> challenge as there is merge of 2 already existing user accounts with
>>>>> various issues related to it (Which roles/permissions should merged
>>>>> account have? Which attributes it should have? Which federation
link?
>>>>> etc.). But at least, I am planning to address the issue with
>>>>> redirect to
>>>>> login forms error screen instead of stay in account management -
>>>>> https://issues.jboss.org/browse/KEYCLOAK-1822
>>>>>
>>>>> Marek
>>>>> _______________________________________________
>>>>> 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>
>>> <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
>> 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
4:42 a.m.
On 28.10.2015 21:32, Bill Burke wrote:
If a user has loads of social networks and links a bunch of them, if
*any one* of them is compromised the entire account is compromised.
Most sites using social login, the only reason is there is a login is
for the appliation to collect marketing data. So, the default behavior
should make things as simple as possible for the user.
At a minimum, by default, the user should not be required to link an
account if there is a conflicting duplicate email given by the provider.
I have found develoeprs.redhat.com very difficult to use.
yep, it is difficult to use because it have to follow company's policy
with unique emails and Keycloak do not provide necessary support for
simple and user friendly account linking currently ;-)
Vl.
On 10/28/2015 12:34 PM, Scott Rehorn wrote:
> I agree with Stian here – the process to normalize a collection of
> logins requires human-interaction nuance that should not be automated. I
> think Keycloak can provide a nice user experience to aid the process,
> but it should always be an interactive process with plenty of
> re-authentication challenges to make sure an individual still retains
> ownership of the various candidate linked accounts.
>
> From: <keycloak-dev-bounces(a)lists.jboss.org
> <mailto:keycloak-dev-bounces@lists.jboss.org>> on behalf of Stian
> Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
> Reply-To: "stian(a)redhat.com <mailto:stian@redhat.com>"
<stian(a)redhat.com
> <mailto:stian@redhat.com>>
> Date: Wednesday, October 28, 2015 at 8:06 AM
> To: Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>>
> Subject: Re: [keycloak-dev] Plan for "First login with identity brokers"
>
> I'm quite concerned about auto linking accounts. If someone has loads of
> social networks enabled and a user has a single of those compromised
> (that happens quite frequently) the attackers would then also be able to
> gain access to whatever Keycloak secures. The user wouldn't even know
> they have access to Keycloak, since the user has never used to
> compromised account to login to Keycloak.
>
> I strongly feel we should never link to any account without requiring
> user to first authenticate to the account we are linking with.
>
> On 27 October 2015 at 08:04, Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> On 27/10/15 14:05, Bill Burke wrote:
> > IMO, most applications will not care about account duplication. Most
> > users won't care about account linking. So, IMO:
> Remember you mentioned that already in the previous discussions. IMO
> people care and usually want to have single account on single site. If
> you have 2 accounts, you never know to which of your accounts you are
> authenticated. This causes various issues, like permissions available to
> account1, but you are logged with account2 etc.
>
> Remember some time ago I messed on some site and have 2 accounts like
> "mposolda" and "mposolda(a)redhat.com
<mailto:mposolda@redhat.com>" .
> I had always issues like that
> when I was logged as "mposolda" I had "Access denied" when
going to page
> I was supposed to have permission. So needed to logout and login again
> as "mposolda(a)redhat.com <mailto:mposolda@redhat.com>" etc.
> >
> > 1) users should not be required to link accounts. In the case where an
> > account cannot be automatically linked a duplicate account should be
> > created
> > 2) Providers should be trusted by default. Trusted providers can just
> > automatically link themselves to existing accounts that were logged in
> > by other trusted providers.
> > 3) Untrusted providers can automatically link if email has been verified
> > for all parties.
> > 4) Users can merge accounts that have verified emails.
> > 5) An alternative to user self merging of account could be requiring to
> > enter in a temporary code after logging into each account.
> >
> >
> > #1 and #2 can be added with minimal changes to code. #3 requires a flow
> > on broker login and a rework of the broker SPI. #4 is account service
> > changes. #5 might be as easy as adding a required action.
> >
> > I guess it depends if ultimate flexibility is needed. #1, #2 and #4
> > might be enough and require the least amount of changes and SPI
refactoring.
> I think that flexibility is needed based on various JIRAs and feedback.
> Just talked with Vlasta Elias from jboss.org <http://jboss.org>;.
> They have even more
> requirements for possible conditions when accounts should be merged and
> how to merge accounts. For example Vlasta mentioned the usecase like:
> - When user logges with Facebook (or other provider) account, which is
> not yet linked to any Keycloak account, then new account on Keycloak
> side shouldn't be created automatically. Even if I logged with Facebook
> bob(a)gmail.com <mailto:bob@gmail.com> and there is no KC account for
> email bob(a)gmail.com <mailto:bob@gmail.com>, there
> is requirement to always show the screen like: "You just logged with
> facebook account bob(a)gmail.com <mailto:bob@gmail.com>. Do you want
> to link it with existing
> keycloak account?" If user agree, he would need to provide Keycloak
> account he wants to merge and then verify email or re-authenticate to
> link Facebook with existing account
>
> - Another use-case was to merge account automatically based on username
> from thirdparty SAML provider. For example the SAMLResponse with
> username "john" returned from SAML provider, there is a need to
> automatically merge it with Keycloak account "john" . In this case,
they
> know that "john" will be always available on Keycloak side because of
> Federation provider, which SAML IDP uses as storage as well.
>
> Based on all of this, it looks that introducing Auth SPI for first time
> broker login is a way to go. This will address all of #1, #2 and #3 and
> many other usecases.
>
> For your #2, I agree that providers should be trusted by default. But
> not all of providers, because some of them don't verify email. AFAIK
> Facebook and Google verify email. But Github doesn't . It will be a
> security hole to trust github provider by default because then user can
> do something like:
> - He can create github account with any email he wants like
> "mposolda(a)redhat.com <mailto:mposolda@redhat.com>"
> - Login with this github account into Keycloak. If we trust the email by
> default, he will be logged into Keycloak to account
> "mposolda(a)redhat.com <mailto:mposolda@redhat.com>", which is not
his
> email -> FAIL
>
> I am not sure about support for merging accounts in Account management
> (like #4 and #5), will try to work on login flow first and will try to
> possibly look at account management then.
>
> Marek
> >
> >
> > On 10/27/2015 4:33 AM, Marek Posolda wrote:
> >> I went again through all the previous discussions, related JIRAs and
> >> requirements. As of now, my plan is to:
> >>
> >> - Use authentication SPI to handle the flow and related actions for
> >> first social login. (Update user profile, Detect duplicated account,
> >> Verify email or reauthenticate user if duplication is detected, Create
> >> social link to existing account). This allows most flexibility for
> >> admins to specify how exactly the linking should work
> >>
> >> - Detecting duplication will be based on email only by default - (For
> >> example duplication is detected if Facebook user with email
> >>bob(a)gmail.com <mailto:bob@gmail.com> authenticates, but there is
> already Keycloak user with
> >> emailbob(a)gmail.com <mailto:bob@gmail.com> ). The people can
provide their
> own execution if
> >> they want different way for detect duplications
> >>
> >> - It seems it's more proper to postpone creating user account
later,
> >> once we know that there is no duplication. In other words, if
"Update
> >> profile on first login" is enabled, the user account is not yet
created
> >> when the update profile page is shown. All the info related to
> >> BrokeredIdentityContext stuff will be available on ClientSession. This
> >> seems to me easier and more proper solution then creating temporary
> >> account with email in some "temporary" attribute. Temporary
accounts
> >> have other challenges (Cleaner thread for delete outdated unmerged
> >> accounts etc).
> >>
> >> - If "trustEmail" flag is on for IdentityProvider, the
provider link
> >> will be created automatically. (For example if Facebook user
> >>bob(a)gmail.com <mailto:bob@gmail.com> authenticates for the first
> time and there is already
> >> Keycloak user with emailbob(a)gmail.com <mailto:bob@gmail.com> and
trustEmail is on, the
> >> Facebook link is automatically created for Keycloak account
> >>bob(a)gmail.com <mailto:bob@gmail.com> without any additional
> verification)
> >>
> >> - If "trustEmail" flag is off, there would need to be other
way to
> >> verify user before creating social link. The user will first confirm if
> >> he wants to merge the accounts. Then there will be either:
> >> -- Email verification: The mail will be sent tobob(a)gmail.com
<mailto:bob@gmail.com> like
> >> "Someone authenticates to Keycloak
serverhttp://www.keycloak.org:8080
> >> through Facebook accountbob(a)gmail.com <mailto:bob@gmail.com> and
wants to link Facebook
> >> account with existing Keycloak accountbob(a)gmail.com
<mailto:bob@gmail.com> . If it is you,
> >> click here" . After user clicks, the social link is created
> >> -- Further authentication: User will need to authenticate to existing
> >>bob(a)gmail.com <mailto:bob@gmail.com> keycloak account through
> password (or OTP or both or
> >> something else)
> >> All of this is configurable through flows, so admin can disable the
"Do
> >> you want to create social link?" screen, or enforce email
verification
> >> instead of authentication, configure required authenticators etc.
> >>
> >> - I am not sure if we want to handle just merge with existing account
> >> during first broker login, or if we also want to handle merging of
> >> accounts in account management? For now, I am planning to handle just
> >> the login flow and possibly address Account management later if there
is
> >> need for it. The merging accounts in account management might be quite
a
> >> challenge as there is merge of 2 already existing user accounts with
> >> various issues related to it (Which roles/permissions should merged
> >> account have? Which attributes it should have? Which federation link?
> >> etc.). But at least, I am planning to address the issue with redirect
to
> >> login forms error screen instead of stay in account management -
> >>https://issues.jboss.org/browse/KEYCLOAK-1822
> >>
> >> Marek
> >> _______________________________________________
> >> 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
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
8:37 a.m.
On 10/29/2015 5:42 AM, Vlastimil Elias wrote:
On 28.10.2015 21:32, Bill Burke wrote:
> If a user has loads of social networks and links a bunch of them, if
> *any one* of them is compromised the entire account is compromised.
> Most sites using social login, the only reason is there is a login is
> for the appliation to collect marketing data. So, the default behavior
> should make things as simple as possible for the user.
>
> At a minimum, by default, the user should not be required to link an
> account if there is a conflicting duplicate email given by the provider.
> I have found develoeprs.redhat.com very difficult to use.
yep, it is difficult to use because it have to follow company's policy
with unique emails and Keycloak do not provide necessary support for
simple and user friendly account linking currently ;-)
Yeah, its not your fault. Its ours.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:35 p.m.
Linking accounts automatically is fine, but we should not have an option
that can do that without requiring users to authenticate first.
There are so many cases where a user could have one social account
compromised. They may not care that much about the account, they may never
use the service so they've completely forgotten about it.
Imagine the following scenario:
* Tom signed up for GMail in 2005 - figured it was great and continued
using the service the rest of his life
* Tom signed up for Twitter in 2005 - figured it was not to his taste and
never used the account again
* Tom now read about two factor auth and configured it on his GMail account
* Mary (a bad person) figured that the password to Toms twitter account was
'password' so she's gained access to Tom's Twitter - Tom doesn't know,
but
he doesn't care either
* Tom signs up for a website that uses Keycloak and logs in with his
trusted GMail account
* Now if we let Mary login to the website that uses Keycloak with Toms old
Twitter account, without first proving she's Tom (which she can't), would
be just plain daft!
On 29 October 2015 at 06:37, Bill Burke <bburke(a)redhat.com> wrote:
On 10/29/2015 5:42 AM, Vlastimil Elias wrote:
>
>
> On 28.10.2015 21:32, Bill Burke wrote:
>> If a user has loads of social networks and links a bunch of them, if
>> *any one* of them is compromised the entire account is compromised.
>> Most sites using social login, the only reason is there is a login is
>> for the appliation to collect marketing data. So, the default behavior
>> should make things as simple as possible for the user.
>>
>> At a minimum, by default, the user should not be required to link an
>> account if there is a conflicting duplicate email given by the provider.
>> I have found develoeprs.redhat.com very difficult to use.
>
> yep, it is difficult to use because it have to follow company's policy
> with unique emails and Keycloak do not provide necessary support for
> simple and user friendly account linking currently ;-)
>
Yeah, its not your fault. Its ours.
--
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
4:08 a.m.
Ok, for now I can do it without possibility for automatic autolink
without re-authentication.
Marek
On 29/10/15 21:35, Stian Thorgersen wrote:
Linking accounts automatically is fine, but we should not have an
option that can do that without requiring users to authenticate first.
There are so many cases where a user could have one social account
compromised. They may not care that much about the account, they may
never use the service so they've completely forgotten about it.
Imagine the following scenario:
* Tom signed up for GMail in 2005 - figured it was great and continued
using the service the rest of his life
* Tom signed up for Twitter in 2005 - figured it was not to his taste
and never used the account again
* Tom now read about two factor auth and configured it on his GMail
account
* Mary (a bad person) figured that the password to Toms twitter
account was 'password' so she's gained access to Tom's Twitter - Tom
doesn't know, but he doesn't care either
* Tom signs up for a website that uses Keycloak and logs in with his
trusted GMail account
* Now if we let Mary login to the website that uses Keycloak with Toms
old Twitter account, without first proving she's Tom (which she
can't), would be just plain daft!
On 29 October 2015 at 06:37, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 10/29/2015 5:42 AM, Vlastimil Elias wrote:
>
>
> On 28.10.2015 21:32, Bill Burke wrote:
>> If a user has loads of social networks and links a bunch of
them, if
>> *any one* of them is compromised the entire account is compromised.
>> Most sites using social login, the only reason is there is a
login is
>> for the appliation to collect marketing data. So, the default
behavior
>> should make things as simple as possible for the user.
>>
>> At a minimum, by default, the user should not be required to
link an
>> account if there is a conflicting duplicate email given by the
provider.
>> I have found develoeprs.redhat.com
<http://develoeprs.redhat.com> very difficult to use.
>
> yep, it is difficult to use because it have to follow company's
policy
> with unique emails and Keycloak do not provide necessary support for
> simple and user friendly account linking currently ;-)
>
Yeah, its not your fault. Its ours.
--
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
9:57 a.m.
There's an alternative problem. Logs in with Twitter in 2005. Logs in
again 2015 with Google. Is required to link with Twitter, says "screw
it" because he doesn't remember his Twitter password and just closes his
browser and doesn't use the website.
I've been on really popular high-traffic sites where their google login
was broken for months (mmqb.si.com which is an NFL website for Sports
Illustrated). I used my Facebook identity instead. If I had been
required to merge accounts manually, I would have not been able to use
the site.
On 10/29/2015 4:35 PM, Stian Thorgersen wrote:
Linking accounts automatically is fine, but we should not have an
option
that can do that without requiring users to authenticate first.
There are so many cases where a user could have one social account
compromised. They may not care that much about the account, they may
never use the service so they've completely forgotten about it.
Imagine the following scenario:
* Tom signed up for GMail in 2005 - figured it was great and continued
using the service the rest of his life
* Tom signed up for Twitter in 2005 - figured it was not to his taste
and never used the account again
* Tom now read about two factor auth and configured it on his GMail account
* Mary (a bad person) figured that the password to Toms twitter account
was 'password' so she's gained access to Tom's Twitter - Tom doesn't
know, but he doesn't care either
* Tom signs up for a website that uses Keycloak and logs in with his
trusted GMail account
* Now if we let Mary login to the website that uses Keycloak with Toms
old Twitter account, without first proving she's Tom (which she can't),
would be just plain daft!
On 29 October 2015 at 06:37, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 10/29/2015 5:42 AM, Vlastimil Elias wrote:
>
>
> On 28.10.2015 21:32, Bill Burke wrote:
>> If a user has loads of social networks and links a bunch of them, if
>> *any one* of them is compromised the entire account is compromised.
>> Most sites using social login, the only reason is there is a login is
>> for the appliation to collect marketing data. So, the default behavior
>> should make things as simple as possible for the user.
>>
>> At a minimum, by default, the user should not be required to link an
>> account if there is a conflicting duplicate email given by the provider.
>> I have founddeveloeprs.redhat.com <http://develoeprs.redhat.com>
very difficult
to use.
>
> yep, it is difficult to use because it have to follow company's policy
> with unique emails and Keycloak do not provide necessary support for
> simple and user friendly account linking currently ;-)
>
Yeah, its not your fault. Its ours.
--
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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:31 a.m.
Would be even simpler for users if we just removed authentication
completely and only had the username on the login form - we could just add
a statement "only use your own username, we trust you to not try to login
as someone else" ;)
Seriously though - social accounts are hacked all the time and allowing
this auto linking of accounts without requiring users to authenticate to
the existing account is just plain scary.
The solution to the use case you've given is not login with another social
provider, it's having good account recovery options in place.
On 30 October 2015 at 14:57, Bill Burke <bburke(a)redhat.com> wrote:
There's an alternative problem. Logs in with Twitter in 2005.
Logs in
again 2015 with Google. Is required to link with Twitter, says "screw it"
because he doesn't remember his Twitter password and just closes his
browser and doesn't use the website.
I've been on really popular high-traffic sites where their google login
was broken for months (mmqb.si.com which is an NFL website for Sports
Illustrated). I used my Facebook identity instead. If I had been required
to merge accounts manually, I would have not been able to use the site.
On 10/29/2015 4:35 PM, Stian Thorgersen wrote:
> Linking accounts automatically is fine, but we should not have an option
> that can do that without requiring users to authenticate first.
>
> There are so many cases where a user could have one social account
> compromised. They may not care that much about the account, they may
> never use the service so they've completely forgotten about it.
>
> Imagine the following scenario:
>
> * Tom signed up for GMail in 2005 - figured it was great and continued
> using the service the rest of his life
> * Tom signed up for Twitter in 2005 - figured it was not to his taste
> and never used the account again
> * Tom now read about two factor auth and configured it on his GMail
> account
> * Mary (a bad person) figured that the password to Toms twitter account
> was 'password' so she's gained access to Tom's Twitter - Tom
doesn't
> know, but he doesn't care either
> * Tom signs up for a website that uses Keycloak and logs in with his
> trusted GMail account
> * Now if we let Mary login to the website that uses Keycloak with Toms
> old Twitter account, without first proving she's Tom (which she can't),
> would be just plain daft!
>
> On 29 October 2015 at 06:37, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
>
>
> On 10/29/2015 5:42 AM, Vlastimil Elias wrote:
> >
> >
> > On 28.10.2015 21:32, Bill Burke wrote:
> >> If a user has loads of social networks and links a bunch of them,
> if
> >> *any one* of them is compromised the entire account is compromised.
> >> Most sites using social login, the only reason is there is a login
> is
> >> for the appliation to collect marketing data. So, the default
> behavior
> >> should make things as simple as possible for the user.
> >>
> >> At a minimum, by default, the user should not be required to link
> an
> >> account if there is a conflicting duplicate email given by the
> provider.
> >> I have founddeveloeprs.redhat.com
<http://develoeprs.redhat.com>
> very difficult
> to use.
> >
> > yep, it is difficult to use because it have to follow company's
> policy
> > with unique emails and Keycloak do not provide necessary support for
> > simple and user friendly account linking currently ;-)
> >
>
> Yeah, its not your fault. Its ours.
>
>
> --
> 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
>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:24 a.m.
I have a prototype in progress, which I am going to present on Thursday
call. It's based on authentication SPI, so it's quite flexible .
Current default behaviour is, when it detects duplicated email, it
displays the page with "Duplication detected. What do you want to do?"
Then user can:
- Go back and edit the profile. So user is not required to link provider
as long as he provides different unique email
- Link the provider. At this point, he need either to reauthenticate by
different way (password+otp or already linked identity provider) or
confirm the linking via email
Marek
On 03/11/15 09:31, Stian Thorgersen wrote:
Would be even simpler for users if we just removed authentication
completely and only had the username on the login form - we could just
add a statement "only use your own username, we trust you to not try
to login as someone else" ;)
Seriously though - social accounts are hacked all the time and
allowing this auto linking of accounts without requiring users to
authenticate to the existing account is just plain scary.
The solution to the use case you've given is not login with another
social provider, it's having good account recovery options in place.
On 30 October 2015 at 14:57, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
There's an alternative problem. Logs in with Twitter in 2005.
Logs in again 2015 with Google. Is required to link with Twitter,
says "screw it" because he doesn't remember his Twitter password
and just closes his browser and doesn't use the website.
I've been on really popular high-traffic sites where their google
login was broken for months (mmqb.si.com <http://mmqb.si.com>
which is an NFL website for Sports Illustrated). I used my
Facebook identity instead. If I had been required to merge
accounts manually, I would have not been able to use the site.
On 10/29/2015 4:35 PM, Stian Thorgersen wrote:
Linking accounts automatically is fine, but we should not have
an option
that can do that without requiring users to authenticate first.
There are so many cases where a user could have one social account
compromised. They may not care that much about the account,
they may
never use the service so they've completely forgotten about it.
Imagine the following scenario:
* Tom signed up for GMail in 2005 - figured it was great and
continued
using the service the rest of his life
* Tom signed up for Twitter in 2005 - figured it was not to
his taste
and never used the account again
* Tom now read about two factor auth and configured it on his
GMail account
* Mary (a bad person) figured that the password to Toms
twitter account
was 'password' so she's gained access to Tom's Twitter - Tom
doesn't
know, but he doesn't care either
* Tom signs up for a website that uses Keycloak and logs in
with his
trusted GMail account
* Now if we let Mary login to the website that uses Keycloak
with Toms
old Twitter account, without first proving she's Tom (which
she can't),
would be just plain daft!
On 29 October 2015 at 06:37, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>
<mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
On 10/29/2015 5:42 AM, Vlastimil Elias wrote:
>
>
> On 28.10.2015 21:32, Bill Burke wrote:
>> If a user has loads of social networks and links a
bunch of them, if
>> *any one* of them is compromised the entire account is
compromised.
>> Most sites using social login, the only reason is there
is a login is
>> for the appliation to collect marketing data. So, the
default behavior
>> should make things as simple as possible for the user.
>>
>> At a minimum, by default, the user should not be
required to link an
>> account if there is a conflicting duplicate email given
by the provider.
>> I have founddeveloeprs.redhat.com
<http://founddeveloeprs.redhat.com>
<http://develoeprs.redhat.com> very difficult
to use.
>
> yep, it is difficult to use because it have to follow
company's policy
> with unique emails and Keycloak do not provide necessary
support for
> simple and user friendly account linking currently ;-)
>
Yeah, its not your fault. Its ours.
--
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>
<mailto:keycloak-dev@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
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:18 a.m.
Sounds good
On 3 November 2015 at 12:24, Marek Posolda <mposolda(a)redhat.com> wrote:
I have a prototype in progress, which I am going to present on
Thursday
call. It's based on authentication SPI, so it's quite flexible .
Current default behaviour is, when it detects duplicated email, it
displays the page with "Duplication detected. What do you want to do?" Then
user can:
- Go back and edit the profile. So user is not required to link provider
as long as he provides different unique email
- Link the provider. At this point, he need either to reauthenticate by
different way (password+otp or already linked identity provider) or confirm
the linking via email
Marek
On 03/11/15 09:31, Stian Thorgersen wrote:
Would be even simpler for users if we just removed authentication
completely and only had the username on the login form - we could just add
a statement "only use your own username, we trust you to not try to login
as someone else" ;)
Seriously though - social accounts are hacked all the time and allowing
this auto linking of accounts without requiring users to authenticate to
the existing account is just plain scary.
The solution to the use case you've given is not login with another social
provider, it's having good account recovery options in place.
On 30 October 2015 at 14:57, Bill Burke <bburke(a)redhat.com> wrote:
> There's an alternative problem. Logs in with Twitter in 2005. Logs in
> again 2015 with Google. Is required to link with Twitter, says "screw it"
> because he doesn't remember his Twitter password and just closes his
> browser and doesn't use the website.
>
> I've been on really popular high-traffic sites where their google login
> was broken for months (mmqb.si.com which is an NFL website for Sports
> Illustrated). I used my Facebook identity instead. If I had been required
> to merge accounts manually, I would have not been able to use the site.
>
> On 10/29/2015 4:35 PM, Stian Thorgersen wrote:
>
>> Linking accounts automatically is fine, but we should not have an option
>> that can do that without requiring users to authenticate first.
>>
>> There are so many cases where a user could have one social account
>> compromised. They may not care that much about the account, they may
>> never use the service so they've completely forgotten about it.
>>
>> Imagine the following scenario:
>>
>> * Tom signed up for GMail in 2005 - figured it was great and continued
>> using the service the rest of his life
>> * Tom signed up for Twitter in 2005 - figured it was not to his taste
>> and never used the account again
>> * Tom now read about two factor auth and configured it on his GMail
>> account
>> * Mary (a bad person) figured that the password to Toms twitter account
>> was 'password' so she's gained access to Tom's Twitter - Tom
doesn't
>> know, but he doesn't care either
>> * Tom signs up for a website that uses Keycloak and logs in with his
>> trusted GMail account
>> * Now if we let Mary login to the website that uses Keycloak with Toms
>> old Twitter account, without first proving she's Tom (which she can't),
>> would be just plain daft!
>>
>> On 29 October 2015 at 06:37, Bill Burke < <bburke(a)redhat.com>
>> bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>>
>>
>> On 10/29/2015 5:42 AM, Vlastimil Elias wrote:
>> >
>> >
>> > On 28.10.2015 21:32, Bill Burke wrote:
>> >> If a user has loads of social networks and links a bunch of them,
>> if
>> >> *any one* of them is compromised the entire account is
>> compromised.
>> >> Most sites using social login, the only reason is there is a
>> login is
>> >> for the appliation to collect marketing data. So, the default
>> behavior
>> >> should make things as simple as possible for the user.
>> >>
>> >> At a minimum, by default, the user should not be required to link
>> an
>> >> account if there is a conflicting duplicate email given by the
>> provider.
>> >> I have founddeveloeprs.redhat.com <
>> http://develoeprs.redhat.com> very difficult
>> to use.
>> >
>> > yep, it is difficult to use because it have to follow company's
>> policy
>> > with unique emails and Keycloak do not provide necessary support
>> for
>> > simple and user friendly account linking currently ;-)
>> >
>>
>> Yeah, its not your fault. Its ours.
>>
>>
>> --
>> 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
>>
>>
>>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
_______________________________________________
keycloak-dev mailing listkeycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:54 a.m.
-100. The default should be to create a duplicate account.
On 11/3/2015 7:18 AM, Stian Thorgersen wrote:
Sounds good
On 3 November 2015 at 12:24, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
I have a prototype in progress, which I am going to present on
Thursday call. It's based on authentication SPI, so it's quite
flexible .
Current default behaviour is, when it detects duplicated email, it
displays the page with "Duplication detected. What do you want to
do?" Then user can:
- Go back and edit the profile. So user is not required to link
provider as long as he provides different unique email
- Link the provider. At this point, he need either to reauthenticate
by different way (password+otp or already linked identity provider)
or confirm the linking via email
Marek
On 03/11/15 09:31, Stian Thorgersen wrote:
> Would be even simpler for users if we just removed authentication
> completely and only had the username on the login form - we could
> just add a statement "only use your own username, we trust you to
> not try to login as someone else" ;)
>
> Seriously though - social accounts are hacked all the time and
> allowing this auto linking of accounts without requiring users to
> authenticate to the existing account is just plain scary.
>
> The solution to the use case you've given is not login with
> another social provider, it's having good account recovery options
> in place.
>
> On 30 October 2015 at 14:57, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> There's an alternative problem. Logs in with Twitter in
> 2005. Logs in again 2015 with Google. Is required to link
> with Twitter, says "screw it" because he doesn't remember his
> Twitter password and just closes his browser and doesn't use
> the website.
>
> I've been on really popular high-traffic sites where their
> google login was broken for months (mmqb.si.com
> <http://mmqb.si.com> which is an NFL website for Sports
> Illustrated). I used my Facebook identity instead. If I had
> been required to merge accounts manually, I would have not
> been able to use the site.
>
> On 10/29/2015 4:35 PM, Stian Thorgersen wrote:
>
> Linking accounts automatically is fine, but we should not
> have an option
> that can do that without requiring users to authenticate
> first.
>
> There are so many cases where a user could have one social
> account
> compromised. They may not care that much about the
> account, they may
> never use the service so they've completely forgotten
> about it.
>
> Imagine the following scenario:
>
> * Tom signed up for GMail in 2005 - figured it was great
> and continued
> using the service the rest of his life
> * Tom signed up for Twitter in 2005 - figured it was not
> to his taste
> and never used the account again
> * Tom now read about two factor auth and configured it on
> his GMail account
> * Mary (a bad person) figured that the password to Toms
> twitter account
> was 'password' so she's gained access to Tom's Twitter -
> Tom doesn't
> know, but he doesn't care either
> * Tom signs up for a website that uses Keycloak and logs
> in with his
> trusted GMail account
> * Now if we let Mary login to the website that uses
> Keycloak with Toms
> old Twitter account, without first proving she's Tom
> (which she can't),
> would be just plain daft!
>
> On 29 October 2015 at 06:37, Bill Burke
> <<mailto:bburke@redhat.com>bburke@redhat.com
> <mailto:bburke@redhat.com>
> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>>
wrote:
>
>
>
> On 10/29/2015 5:42 AM, Vlastimil Elias wrote:
> >
> >
> > On 28.10.2015 21:32, Bill Burke wrote:
> >> If a user has loads of social networks and links a
> bunch of them, if
> >> *any one* of them is compromised the entire account
> is compromised.
> >> Most sites using social login, the only reason is
> there is a login is
> >> for the appliation to collect marketing data. So,
> the default behavior
> >> should make things as simple as possible for the user.
> >>
> >> At a minimum, by default, the user should not be
> required to link an
> >> account if there is a conflicting duplicate email
> given by the provider.
> >> I have founddeveloeprs.redhat.com
> <http://founddeveloeprs.redhat.com>
> <http://develoeprs.redhat.com> very difficult
> to use.
> >
> > yep, it is difficult to use because it have to
> follow company's policy
> > with unique emails and Keycloak do not provide
> necessary support for
> > simple and user friendly account linking currently ;-)
> >
>
> Yeah, its not your fault. Its ours.
>
>
> --
> 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>
> <mailto:keycloak-dev@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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:36 a.m.
On 11/3/2015 3:31 AM, Stian Thorgersen wrote:
Would be even simpler for users if we just removed authentication
completely and only had the username on the login form - we could just
add a statement "only use your own username, we trust you to not try to
login as someone else" ;)
Seriously though - social accounts are hacked all the time and allowing
this auto linking of accounts without requiring users to authenticate to
the existing account is just plain scary.
Sensitive sites do not use social login to protect their users.
The solution to the use case you've given is not login with
another
social provider, it's having good account recovery options in place.
I hope the argument here is just what the default should be.
IMO, the default should be that a new account per social provider is
created and email duplicates are allowed. User would manually merge
accounts via the account service panel if they want.
These features are equally important IMO:
* Broker providers should be able to be automatically trusted with a
switch and automatically merge accounts.
* brokers should have a flow attached to them so that they can require
account merging and such.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:26 a.m.
On 03/11/15 15:36, Bill Burke wrote:
I hope the argument here is just what the default should be.
IMO, the default should be that a new account per social provider is
created and email duplicates are allowed. User would manually merge
accounts via the account service panel if they want.
-1 for allow email duplicates.
If you login through Facebook and there
is already user with email mposolda(a)gmail.com how you would create new
account? Save the email into some different attribute "email_no2" ?
Isn't it just ugly workaround to bypass our unique constraint for
emails? Then if user wants to login in username/password form and he
fills mposolda(a)gmail.com in login form, which account it should use? The
first one or the second one?
TBH allowing email duplications would be confusing for users. They will
mess the accounts without knowing which of their account are they
currently using.
In classic registration form, we don't allow email duplications and we
just display error message "Email already exists". User needs to use
different email or restore his first account ( via "Forget password" or
contacting admin etc). Not sure why this behaviour should be different
for registration via identity provider.
These features are equally important IMO:
* Broker providers should be able to be automatically trusted with a
switch and automatically merge accounts.
* brokers should have a flow attached to them so that they can require
account merging and such.
Merging 2 existing users in account management would be
nice to have.
Question is if we really needs it as it is a bit complex thing and
nobody really quested it so far AFAIK?
Anyway some idea how it could work:
* User is logged in account management as "user2" in "Federated
identities" tab. He clicks to "Link my account with Twitter"
* He login to twitter, but there is already existing Keycloak user
"user1" linked to this Twitter account
* Account management will display message "There is already existing
user user1 linked to Twitter. Do you want to merge accounts?"
* User clicks "yes" . There might be some additional verification
configured in the flow (for example email confirmation). But not sure if
it's critical as user is already able to login as "user1" via Twitter,
so he is already proved to be owner of both accounts.
* Now the merging itself can work like:
-- user1 will have flag MERGED on his account with the attribute
"parent_user" pointing to user2 .
-- user2 will be added to all roles and groups, which user1 had. So
defacto user2 will have union of roles+groups of both users.
-- All attributes of user1 will be merged to user2 . If there is
attribute "foo" available on both user and there are conflicting user,
the original value of user2 will be kept.
-- User2 will be added to all federated identities of user1. Again, if
there is conflict (For example if both users have different Facebook
identity), the original user2 federated identity has preference.
-- Account "user1" will become decomissioned and it's not possible
anymore to login into it. When user later authenticates as user1 with
his user1 password, he will be authenticated as user2 instead.
WDYT? Should I go this way?
Marek
3110
days inactive
3118
days old
19 comments
6 participants
participants (6)
-
Bill Burke -
Marek Posolda -
Scott Rehorn -
Scott Rossillo -
Stian Thorgersen -
Vlastimil Elias