Repository navigation
Experimental SPIFFE identity provider - #42314
Conversation
There was a problem hiding this comment.
The idea you proposed around separating the different aspects of the trust relationship with an identity provider should make this provider a lot simpler given that we won't need to override a lot of the methods here, right?
It should avoid decoupling the different types of providers and avoid, for instance, having spifee as an OAuth2-based broker. Or is that the case?
There was a problem hiding this comment.
Yeah, so SPIFFE should only implement the methods for client assertions and nothing else. Basically move all methods from IdentityProvider to UserIdentityProvider or somethi 8000 ng like that. We also need to figure out something around configuration as there's a ton of config options only applicable to user federation, but that are part of the core IdP model stuff.
There was a problem hiding this comment.
+1 for that. For token-exchange, we already have interfaces like for example ExchangeExternalToken if IDPs supports external-internal token exchange etc.
For the configuration, we use inheritance right now (EG. OIDCIdentityProviderConfig extends from OAuth2IdentityProviderConfig ), but maybe we can use a bit different approach, which may allow that some IDP requires multiple "kinds" of configurations (EG. if it supports for example both user-authentication as well as ClientAssertions)
There was a problem hiding this comment.
I'll create a follow-up issue for this; for now made a note here #42230
a70fc76 to
83913db
Compare
Closes keycloak#42313 Signed-off-by: stianst <stianst@gmail.com>
| return Algorithm.ES512; | ||
| } | ||
| } | ||
| case KeyType.RSA: |
There was a problem hiding this comment.
There is probably similar that for KeyType.OKP , the Algorithm is EdDSA . But possibly this case could added/tested as a follow-up though... I can do that in the follow-up as I am looking at some DPoP related task, which is related: #42286
There was a problem hiding this comment.
Yup, I think we can extend on this quite a bit, but probably easier just as follow-ups when needed
There was a problem hiding this comment.
+1 for that. For token-exchange, we already have interfaces like for example ExchangeExternalToken if IDPs supports external-internal token exchange etc.
For the configuration, we use inheritance right now (EG. OIDCIdentityProviderConfig extends from OAuth2IdentityProviderConfig ), but maybe we can use a bit different approach, which may allow that some IDP requires multiple "kinds" of configurations (EG. if it supports for example both user-authentication as well as ClientAssertions)
Closes #42313
Signed-off-by: stianst stianst@gmail.com