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

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(a)redhat.com <mailto:bburke@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(a)redhat.com > <mailto:bburke@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(a)redhat.com <mailto:bburke@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(a)lists.jboss.org >>> <mailto:keycloak-user@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(a)lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> <https://lists.jboss.org/mailman/listinfo/keycloak-user> >>