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