[keycloak-dev] Plan for "First login with identity brokers"
Bill Burke
bburke at redhat.com
Wed Oct 28 16:32:27 EDT 2015
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 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>>
> Reply-To: "stian at redhat.com <mailto:stian at redhat.com>" <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>>
> Cc: keycloak-dev <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>" .
> 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>" 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 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>, there
> is requirement to always show the screen like: "You just logged with
> facebook account 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>"
> - 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>", 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> 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> authenticates for the first
> time and there is already
> >> Keycloak user with 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> 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: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> 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 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
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> 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
More information about the keycloak-dev
mailing list