Replies: 2 comments
-
|
Pinging @stianst and @slaskawi on this one. Some thoughts: Having a provider for each cloud service would make things simpler for users, still in the past we've postponed adding specific providers as we didn't have the means to integration test them. So you might need to make the case why this is not needed here, or on how to test such setups in a simple manner. Providing just documentation might be the first step, and might also allow us adding a disclaimer / removing the need to support it downstream as it might be upstream only. We've done something like this for XAUTH2 for the SMTP email sending, see https://www.keycloak.org/docs/latest/server_admin/index.html#xoauth2-email-configuration-with-third-party-vendors So I'm all in for adding documentation example if we choose not to have a native integration (yet). |
Beta Was this translation helpful? Give feedback.
-
|
The #48130 discussion is also related to this topic. In general, I'm definitely in favor of this feature. Having individual IdPs would improve the "turnkey" experience of Keycloak. The biggest roadblock here is testing - how to effectively test Keycloak in all these environments and who should maintain them? Such a task is definitely beyond the small maintainer team and I suggest to figure out a way to try to involve community here. I have a lot of thoughts on how to do it but I don't want to derail this discussion here. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
With the recent support of RFC 7521/7523 (Client Authentication variant) and its SPIFFE profile it is technically possible to leverage the identity cloud providers give each instance as a mean of client authentication.
Docs from the biggest 3:
I would like to propose Identity Provider for each of those to make it easier to configure Workload Identity-based client authentication. A cloud-provider specific Identity Provider would for instance not accept an issuerUrl but the organization identifier, such as the AWS Account ID. Or in Entra, the tenant ID. Each client would then configure the cloud specific identifier, such as the principalID in Entra or the AWS ARN.
On a more higher level, there's a informational IETF document outlines the various Workload Identity Practices that exist today. Keycloak supports 2 natively, Kubernetes & SPIFFE. The remaining big ones are: Service Meshes, Cloud Providers and CI/CD.
As an alternative it would also possible to provide appropriate documentation and examples but I believe a more native integration is more attractive and is less-error prone.
Beta Was this translation helpful? Give feedback.
All reactions