[keycloak-dev] Plan for "First login with identity brokers"
Marek Posolda
mposolda at redhat.com
Thu Oct 29 04:05:41 EDT 2015
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.
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
>> <mailto: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>
>>> <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: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: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: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/0a743933/attachment-0001.html
More information about the keycloak-dev
mailing list