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@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
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@gmail.com
<mailto:bob@gmail.com>
authenticates for the first
time and there is already
Keycloak user
with emailbob@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 tobob@gmail.com
<mailto:bob@gmail.com>
like
"Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080
through Facebook accountbob@gmail.com
<mailto:bob@gmail.com>
and wants to link Facebook
account with existing Keycloak 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@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@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
_______________________________________________
keycloak-dev mailing list
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev