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

[Bill Burke]

You want to be able to store account links within a different datastore.


On 8/4/16 9:59 AM, Josh Cain wrote:
> Not 100% sure what that question is asking; I'd like to provide social 
> auth credential -> Keycloak UserModel associations using another 
> source than the Keycloak database.
>
> Josh Cain | Software Applications Engineer
> /Identity and Access Management/
> *Red Hat*
> +1 843-737-1735
>
> On Thu, Aug 4, 2016 at 8:47 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     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 <tel:%2B1%20843-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/757b04bb/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/757b04bb/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/757b04bb/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/757b04bb/attachment-0005.png