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

[Bill Burke]

Ok, I'll have to add that to the roadmap.  I'm currently creating a 
brand new user federation SPI.  I was assuming account linking would be 
completely managed by keycloak.


On 8/4/16 10:14 AM, Josh Cain wrote:
> Yes, I think we're on the same page now!
>
>
> Josh Cain | Software Applications Engineer
> /Identity and Access Management/
> *Red Hat*
> +1 843-737-1735
>
> On Thu, Aug 4, 2016 at 9:06 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     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 <tel:%2B1%20843-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/21846776/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/21846776/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/21846776/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/21846776/attachment-0005.png