7:19 p.m.
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
8:35 p.m.
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
https://lists.jboss.org/mailman/listinfo/keycloak-user
8:32 a.m.
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
On Wed, Aug 3, 2016 at 8:35 PM, Bill Burke <bburke(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
8:47 a.m.
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
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>
8:59 a.m.
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(a)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
On Wed, Aug 3, 2016 at 8:35 PM, Bill Burke <bburke(a)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
>
>
> _______________________________________________
> keycloak-user mailing
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________ keycloak-user mailing
> list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailma
> n/listinfo/keycloak-user
9:06 a.m.
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(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>
>
9:14 a.m.
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> 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(a)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(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> _______________________________________________ keycloak-user mailing
>> list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailma
>> n/listinfo/keycloak-user
>
>
9:17 a.m.
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(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>
>>
9:20 a.m.
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(a)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(a)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(a)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(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> _______________________________________________ keycloak-user mailing
>>> list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailma
>>> n/listinfo/keycloak-user
>>
>>
3080
days inactive
3080
days old
8 comments
2 participants
participants (2)
-
Bill Burke -
Josh Cain