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

Marek Posolda mposolda at redhat.com
Tue Oct 27 04:33:44 EDT 2015


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


More information about the keycloak-dev mailing list