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

Josh Cain josh.cain at redhat.com
Thu Aug 4 10:14:52 EDT 2016


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> 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
>
> On Thu, Aug 4, 2016 at 8:47 AM, Bill Burke <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 <%2B1%20843-737-1735>
>>
>> On Wed, Aug 3, 2016 at 8:35 PM, Bill Burke <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 <%2B1%20843-737-1735>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> _______________________________________________ keycloak-user mailing
>>> list keycloak-user at lists.jboss.org https://lists.jboss.org/mailma
>>> n/listinfo/keycloak-user
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160804/43348c45/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/43348c45/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/43348c45/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/43348c45/attachment-0005.png 


More information about the keycloak-user mailing list