Repository navigation
Replies: 8 comments 5 replies
|
Somehow I missed this statement in the document I posted: Keycloak requires the sub claim in the assertion to be the user identifier in the external provider. The Keycloak user should be previously linked to the Identity Provider. This way there is a link between the external and the internal user ID. Which I guess answers my initial question. Is there anyway that the linking of the user and the keycloak user can be automated? |
|
I have the same problem. Does it only work right now if we link all users manually? |
|
It would seem that this is the case, and that the change is intentional:
Further to this it also seems that if the user does already exist, then the federated identity is not imported into Keycloak meaning that the external IDP cannot be the single source of truth for roles and groups when authenticating solely using this method. it does look like importing a federated identity is supported in the external to internal token exchange provider:
However, this is currently an experimental feature (not even preview), and it is not clear to me exactly how this would interact with the 'JWT Authorization Grant'. |
|
I face the same. If any solutions for this |
|
Same here. Maybe there are already security concerns we don't know? |
|
To import external users into Keycloak with JWT Authorization Grant, we extended |
|
Potentially using the above solution, but ideally would want to handle this without a custom provider |
|
SCIM seemed like an excellent use case for this - however the external IdP we want to use is Entra, which refuses to sync Service Principals (the "users" associated with confidential clients/"App Registrations" in Entra) |
|
I've tried adding the JWT authorization grant IdP as an OIDCv1 type IdP as well and it doesn't create the users like it does for authorization code flow. I'm exploring SCIM to allow Entra to push Service Principals into Keycloak but the permissions model is too coarse for the ABAC I would expect to limit an SCIM client principal from being able to manage users it doesn't actually own. |
|
Update on this: I followed tutorials on FGAP for admin API but I cannot get SCIM API to be limited for a given OIDC client to only access a subset of users. Either SCIM can see everything or nothing. This combined with being unable to enforce organization or group membership on SCIM-created users makes SCIM a dead end, sadly. |
|
Update: I was able to get the SCIM user limiter permissions but Entra's SCIM server feature refuses to push Service Principals |
|
@OskarPetto can you share some reference on the custom implementation. Facing similar problem want to provision user dynamically with the source sub |
|
As To achieve this, we extended validateAuthorizationGrantAssertion(context) {
brokeredIdentityContext = super.validateAuthorizationGrantAssertion(context);
if (brokeredIdentityContext == null) {
throw new RuntimeException("Error validating JWT with identity provider");
}
// Equivalent to the logic in lines 112-113 of JWTAuthorizationGrantType
lookUpUser();
if (user == null) {
createUser();
}
addClaimsToUserAttributes();
}This ensures that the user is created (if necessary) before |
Uh oh!
There was an error while loading. Please reload this page.
I have been investigating the preview feature 'JWT Authorization Grant' https://www.keycloak.org/securing-apps/jwt-authorization-grant for external to internal token exchange and have found that I can generate a token in the configured Okta IDP and then exchange that Token using the end point /realms/{realim}/protocol/openid-connect/token for a Keycloak token.
The end goal of this work is to allow a third party application pass an IDP token to our application which will then authenticate with Keycloak using the IDP token.
This works, as long as the IDP user already exists in Keycloak. If the IDP user does not exist in Keycloak I get a 'user not found' error.
If I login using the browser for the same IDP I can use the first broker login flow to automatically create the user.
My questions are:
All reactions