Repository navigation
Replies: 5 comments 3 replies
|
We'd need to introduce some flags on identity providers to be able to enable/disable capabilities. For example an OIDC provider could have options like:
The Admin UI would then need to be updated to hide/show relevant config options based on what capabilities are enabled (similarly to what we do for clients). |
|
I can see that too. |
|
One thing to consider is whether or not identity provider remains a valid name. It may be still valid as in all above cases we are talking about something that either provides or validates identities of some sort (be it users or clients). However, a more ideal name may be something like |
|
Not sure about that. I think it boils down to three main capabilities around cross-domain trust:
And a mix and match of them, depending on the trust relationship and the capabilities of the trusted domains . |
|
I'd like to move user federation related methods from IdentityProvider into a separate UserFederation interface or something like that; will require some refactor as well as breaking changes to APIs though |
|
Makes sense to me. Brokering and identity/user federation are separate capabilities, which can co-exist or not when creating a bridge between different security domains. |
I think it boils down to three main capabilities around cross-domain trust:
A security token service (sts) is basically token exchange and client assertions, where tokens are issued, validated, renewed, etc. The RFC RFC7523 kinda provides a framework for that. As well as token exchange, but will have a lot more capabilities and semantics around it. An STS goes beyond authentication/verification of tokens to also support validation, renewal, and revocation. An identity broker is what we currently have as "identity providers", where a client (browser) can authenticate across different security domains to be able to access protected resources in one of the domains. But this concept can be extended to clients, as you mentioned, so that you can, for instance, have a broker acting as the intermediary to authenticate users/clients based on certificates from another security domain. For instance, a generic Identity federation is basically about federating identities from other domains, and that can happen when doing both STS and brokering. As you mentioned, it is more of an orthogonal capability than something by itself. For instance, today an identity provider/broker is tightly related to identity/user federation.
I see it as a generic
This kinda shows the overlap between a broker and a security token service/broker. As you mentioned, they are different brokering capabilities. The fact you can authenticate through an 3rd party IdP does not mean you can also exchange their tokens with internal ones, and vice versa. |
|
We're going ahead with this idea. It was partially done as we introduced federated client authentication, but there is more work needed that is being planned in #43486 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
An identity provider in Keycloak establishes a trust relationship with an external identity provider, allowing federated authentication of users.
There are a number of use-cases related to establishing trust with a third-party, for example:
We could of course introduce separate concepts of trusts, from the examples above we could have the following concepts within realm in addition to identity providers:
An alternative approach and what this proposal is about is to add capabilities to the concept of identity providers. This already exists to some extent as we have IdentityProvider that can be extended with ExchangeExternalToken to support one of the use-cases above.
Having a single place to manage trust relationships would be better for a user than having to deal with multiple concepts. This is especially important in cases when a single trust relationship supports more than one of the previously mentioned use-cases. For example Keycloak and use OpenShift as an identity provider to authenticate users, but can also use the same OpenShift deployment to authenticate clients via service accounts. Another example would be SPIFFE which can issue both X.509 and JWT SVIDs with a single SPIFFE identity provider it would be possible to trust both or one, while if separate concepts you'd need to configure it twice.
As a more concrete example on how this would be used we would introduce a
ClientAssertionIdentityProviderthat is able to authenticate clients with client assertions. The identity provider would do the heavy lifting of validating the assertion, with a client authenticator where a client can be configured to use externally issued client assertions from a given identity provider to authenticate. The authenticator would simply just pass the client assertion to the identity provider, allowing the identity provider itself to decide how to verify the assertion.All reactions