[keycloak-dev] Plan for "First login with identity brokers"

Marek Posolda mposolda at redhat.com
Tue Oct 27 11:04:38 EDT 2015


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" . 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" 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. 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 and there is no KC account for email bob at gmail.com, there 
is requirement to always show the screen like: "You just logged with 
facebook account 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"
- 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", 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 authenticates, but there is already Keycloak user with
>> email 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 authenticates for the first time and there is already
>> Keycloak user with email bob at gmail.com and trustEmail is on, the
>> Facebook link is automatically created for Keycloak account
>> 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 to bob at gmail.com like
>> "Someone authenticates to Keycloak server http://www.keycloak.org:8080
>> through Facebook account bob at gmail.com and wants to link Facebook
>> account with existing Keycloak account 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 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
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>



More information about the keycloak-dev mailing list