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

[Josh Cain]

Cool, thanks Bill!

We've got some upcoming integrations where this would be a huge win for
us.  I'd be happy to jump in and help if you have a specific change in
mind, just let me know.

Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735

On Thu, Aug 4, 2016 at 9:17 AM, Bill Burke <bburke at redhat.com> wrote:

> 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> 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 <%2B1%20843-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/ec042f60/attachment-0001.html 
-------------- 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/ec042f60/attachment-0003.png 
-------------- 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/ec042f60/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/ec042f60/attachment-0005.png