[keycloak-dev] Plan for "First login with identity brokers"
Vlastimil Elias
velias at redhat.com
Thu Oct 29 05:44:18 EDT 2015
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 at gmail.com <mailto:me at 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 at smartling.com <mailto:srossillo at smartling.com>
>>
>> Powered by Sigstr <http://www.sigstr.com/>
>>
>>> On Oct 28, 2015, at 4:32 PM, Bill Burke <bburke at 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 at lists.jboss.org
>>>> <mailto:keycloak-dev-bounces at lists.jboss.org>
>>>> <mailto:keycloak-dev-bounces at lists.jboss.org>> on behalf of Stian
>>>> Thorgersen <sthorger at redhat.com <mailto:sthorger at redhat.com>
>>>> <mailto:sthorger at redhat.com>>
>>>> Reply-To: "stian at redhat.com <mailto:stian at redhat.com>
>>>> <mailto:stian at redhat.com>" <stian at redhat.com <mailto:stian at redhat.com>
>>>> <mailto:stian at redhat.com>>
>>>> Date: Wednesday, October 28, 2015 at 8:06 AM
>>>> To: Marek Posolda <mposolda at redhat.com <mailto:mposolda at redhat.com>
>>>> <mailto:mposolda at redhat.com>>
>>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org
>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>> <mailto:keycloak-dev at 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 at redhat.com
>>>> <mailto:mposolda at 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 at redhat.com <mailto:mposolda at redhat.com>
>>>> <mailto:mposolda at 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 at redhat.com <mailto:mposolda at redhat.com>
>>>> <mailto:mposolda at 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 at gmail.com <mailto:bob at gmail.com> <mailto:bob at gmail.com> and
>>>> there is no KC account for
>>>> email bob at gmail.com <mailto:bob at gmail.com>
>>>> <mailto:bob at gmail.com>, there
>>>> is requirement to always show the screen like: "You just logged with
>>>> facebook account bob at gmail.com <mailto:bob at gmail.com>
>>>> <mailto:bob at 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 at redhat.com <mailto:mposolda at redhat.com>
>>>> <mailto:mposolda at 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 at redhat.com <mailto:mposolda at redhat.com>
>>>> <mailto:mposolda at 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 at gmail.com <mailto:bob at gmail.com> <mailto:bob at gmail.com>
>>>>>> authenticates, but there is
>>>> already Keycloak user with
>>>>>> emailbob at gmail.com <mailto:bob at 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 at gmail.com <mailto:bob at gmail.com> <mailto:bob at gmail.com>
>>>>>> authenticates for the first
>>>> time and there is already
>>>>>> Keycloak user with emailbob at gmail.com <mailto:emailbob at gmail.com>
>>>>>> <mailto:bob at gmail.com> and trustEmail is on, the
>>>>>> Facebook link is automatically created for Keycloak account
>>>>>> bob at gmail.com <mailto:bob at gmail.com> <mailto:bob at 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 at gmail.com
>>>>>> <mailto:bob at gmail.com> like
>>>>>> "Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080
>>>>>> through Facebook accountbob at gmail.com
>>>>>> <mailto:accountbob at gmail.com> <mailto:bob at gmail.com> and wants to
>>>>>> link Facebook
>>>>>> account with existing Keycloak accountbob at gmail.com
>>>>>> <mailto:bob at 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 at gmail.com <mailto:bob at gmail.com> <mailto:bob at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/b516ef2d/attachment-0001.html
More information about the keycloak-dev
mailing list