[keycloak-user] External Source of Truth for Federated Identities (Social Auth)

[Bill Burke]

So you basically want to choose which provider a social login (brokered 
login) gets imported into?


On 8/4/16 9:32 AM, Josh Cain wrote:
> We've got social auth data already in a data store, and other 
> applications/enclaves also use that data store, so we'd like to keep 
> it as a single source of truth (rather than point additional 
> applications to the KC database, or require users to link the same 
> account manually again).
>
> Maybe in pictures would help.  The diagram below would give a 
> high-level understanding of how the current user search works with 
> federation providers:
>
> ​
> Contrast this with the current social auth user lookup process like 
> this (example using Github, but any social auth provider really):
>
>
> ​
> When the IDP swaps the auth code for the access token and is able to 
> view the user's third party information (userId, name, etc), this 
> information is referenced against the Keycloak database *only*.  I'd 
> ideally like to be able to consult an external lookup in order to see 
> if something else was capable of associating this third party 
> information with a Keycloak UserModel.  I was wondering if a flow 
> similar to the user's federation provider flow would be possible - 
> something like this:
>
>
> ​
> Would extending Keycloak to include and SPI for this be an option?  
> Thoughts?
>
> I looked at simply altering/delegating one of the existing 
> UserProvider implementations, but it just feels wrong.
>
>
> Josh Cain | Software Applications Engineer
> /Identity and Access Management/
> *Red Hat*
> +1 843-737-1735
>
> On Wed, Aug 3, 2016 at 8:35 PM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Huh?  I don't understand.
>
>
>     On 8/3/16 8:19 PM, Josh Cain wrote:
>>     Hi all,
>>
>>     I'm in a situation in which I need to consult an external source
>>     of truth in order to pull social auth credentials (outside the
>>     Keycloak database).  I'd ideally like something functionally
>>     equivalent to the UserFederationProvider, in which another source
>>     outside the user store is consulted for this information.  Is
>>     anything like that currently supported?
>>
>>     Josh Cain | Software Applications Engineer
>>     /Identity and Access Management/
>>     *Red Hat*
>>     +1 843-737-1735 <tel:%2B1%20843-737-1735>
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>     <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>     _______________________________________________ keycloak-user
>     mailing list keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>     <https://lists.jboss.org/mailman/listinfo/keycloak-user> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160804/7d4a4e24/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 40225 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160804/7d4a4e24/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 27391 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160804/7d4a4e24/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 44930 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160804/7d4a4e24/attachment-0005.png