Josh Cain | Software Applications Engineer
Identity and Access Management+1 843-737-1735
On Thu, Aug 4, 2016 at 9:17 AM, Bill Burke <bburke@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!
Red HatJosh Cain | Software Applications EngineerIdentity and Access Management
+1 843-737-1735
On Thu, Aug 4, 2016 at 9:06 AM, Bill Burke <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.
Red HatJosh Cain | Software Applications EngineerIdentity and Access Management
+1 843-737-1735
On Thu, Aug 4, 2016 at 8:47 AM, Bill Burke <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:
Contrast this with the current social auth user lookup process like this (example using Github, but any social auth provider really):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:
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.
Red HatJosh Cain | Software Applications EngineerIdentity and Access Management
+1 843-737-1735
On Wed, Aug 3, 2016 at 8:35 PM, Bill Burke <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?
Red HatJosh Cain | Software Applications EngineerIdentity and Access Management
+1 843-737-1735
_______________________________________________ keycloak-user mailing list keycloak-user@lists.jboss.org https://lists.jboss.org/mailma n/listinfo/keycloak-user _________________ keycloak-user mailing list keycloak-user@lists.jboss.org https://lists.jboss.org/mailma n/listinfo/keycloak-user