Repository navigation
Keep the organization invitation through broker login - #52183
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Preserves organization invitations across first-broker login so invited users can join through realm-level identity providers.
Changes:
- Stores and preserves the organization ID across authentication resets.
- Accepts matching pending invitations during broker onboarding.
- Adds an integration test for the successful flow.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
OrganizationInvitationLinkTest.java |
Tests broker-based invitation acceptance. |
IdentityBrokerService.java |
Preserves organization state across flow reset. |
AuthorizationEndpoint.java |
Copies organization context into the authentication session. |
IdpAddOrganizationMemberAuthenticator.java |
Consumes matching invitations and adds unmanaged membership. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+63
to
+64
| provider.addMember(organization, user); | ||
| provider.getInvitationManager().remove(invitation.getId()); |
SferaDev
force-pushed
the
invite-org-broker-membership
branch
from
August 28, 2026 14:25
c6c9e7e to
bcd4950
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
Suppressed comments (2)
services/src/main/java/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java:412
- Only preserving the organization drops the invitation's redirect URI. Registration links do not put a
redirect_uriin the authorization request, and the normal registration path later appliesInviteOrgActionToken#getRedirectUri; this broker path bypasses that code, so invitations using an organization's custom redirect URL return to the account client's default URL instead. Preserve and apply the invitation redirect state across the broker round trip as well.
OrganizationModel organization = session.getContext().getOrganization();
if (organization != null) {
authenticationSession.setAuthNote(OrganizationModel.ORGANIZATION_ATTRIBUTE, organization.getId());
services/src/main/java/org/keycloak/organization/authentication/authenticators/broker/IdpAddOrganizationMemberAuthenticator.java:70
- This consumes an organization invitation without emitting the
INVITE_ORGsuccess event. Both existing invitation-consumption paths emit that event (including user and organization details), so broker-accepted invitations will be absent from event listeners and audit logs; emit the same event before completing the flow and assert it in the new test.
provider.addMember(organization, user);
provider.getInvitationManager().remove(invitation.getId());
SferaDev
force-pushed
the
invite-org-broker-membership
branch
from
August 28, 2026 16:21
bcd4950 to
377b7dd
Compare
SferaDev
force-pushed
the
invite-org-broker-membership
branch
from
August 28, 2026 19:51
377b7dd to
70101dc
Compare
SferaDev
force-pushed
the
invite-org-broker-membership
branch
from
August 28, 2026 19:59
70101dc to
b77b399
Compare
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#employee2TestKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#testUserAttributeStatementMapperUserGroupsAggregateKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#testUserAttributeStatementMapperGroupsNoAggregateKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#singleLoginAndLogoutSAMLTestKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#salesPostTestCom F438 positeRoleForUserKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#salesPostEmptyConsumerPostURLKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#testUserAttributeStatementMapperGroupsAggregateKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#testReloginWithInvalidAuthSessionCookieKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#salesPostTestKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#salesPostSigTransientTestKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#testUserAttributeStatementMapperUserGroupsNoAggregateKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#salesPostSigTestKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#disabledClientTestKeycloak CI - Adapter IT Strict Cookies org.keycloak.testsuite.adapter.servlet.SAMLServletAdapterTest#testMultipleTabsParallelLoginKeycloak CI - Adapter IT Strict Cookies |
SferaDev
force-pushed
the
invite-org-broker-membership
branch
from
August 29, 2026 06:15
b77b399 to
1a3028c
Compare
| @@ -52,6 +58,26 @@ protected void authenticateImpl(AuthenticationFlowContext context, SerializedBro | |||
| return; | |||
| } | |||
|
|
|||
| InviteOrgActionToken invitation = getPendingInvitation(session, organization, user); | |||
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.broker.KcOidcBrokerTest#loginWithExistingUserWithBruteForceEnabledKeycloak CI - Java Distribution IT (windows-latest - temurin - 17) |
Closes keycloak#52181 Signed-off-by: Alexis Rico <sferadev@gmail.com>
SferaDev
force-pushed
the
invite-org-broker-membership
branch
from
August 31, 2026 06:00
1a3028c to
d2a5f84
Compare
pedroigor
approved these changes
Sep 14, 2026
Contributor
|
@SferaDev I would appreciate an update to the docs with something like this, perhaps also make clear the binding between the invite token and the auth session, and the final check on match the email from the (authenticated) user and from the token. Wondering if we should make very clear that the assumption is that as long as the user can authenticate using the same email, they will be able to join the org. |
Contributor
Author
|
@pedroigor What about something like this? #52755 |
xata-bot
pushed a commit
to xataio/xata
that referenced
this pull request
Oct 6, 2026
* [Roles] Treat removing a user from a group they are not in as done Keycloak 26.8 answers a DELETE on an organization group member who is not in the group with 400 "User not a member" (keycloak/keycloak#52588), where 26.7 answered 204. Changing a role clears every other role group, and removing a member clears all of them, so almost every call lands on a group the user was never in. On 26.8 each of those would fail the role change or member removal. Match the message as well as the status, since 400 also covers malformed requests. Verified against a Keycloak built from main: 26.7.3 returns 204 and the 26.8 build returns 400 {"errorMessage":"User not a member"}. Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * [Auth] Keep Keycloak 26.8 domain routing through organization updates Keycloak 26.8 moves an organization's SSO routing off the identity provider config and onto each domain, as identityProviderAlias and autoRedirect (keycloak/keycloak#52401). Its migration copies the existing kc.org.domain and redirect-on-email-match config across and deletes it. From then on an organization PUT replaces every domain with what it carries, so a domain sent without those fields loses its provider and redirect. Domain carried only name and verified, so every organization update maki makes (billing, pending SSO domains, SetOrganizationDomains) would silently turn SSO enforcement off on 26.8. Round-trip both fields, omitted when unset. 26.7.3 answers 400 "Unrecognized field identityProviderAlias" for a domain carrying either, and never returns them, so this changes nothing before the upgrade and must land before it. Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * Trim comments Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * [Keycloak] Upgrade to 26.8.0 Keycloak 26.8 moves organization domain routing off identity provider config and onto each organization domain (keycloak/keycloak#52401). It deletes OrganizationModel.ORGANIZATION_DOMAIN_ATTRIBUTE, ORGANIZATION_EXCLUDED_DOMAIN_ATTRIBUTE and IdentityProviderRedirectMode, so the extensions no longer compile, and its migration removes the config keys DomainSso read, so the old logic would have found nothing to enforce. DomainSso now reads the routing from the most specific matching organization domain, as OrganizationAuthenticator does. A subdomain held without a provider opts out of a wildcard that has one, which replaces the excluded-domains list. assertsOwnDomain binds a provider to the domains routed to it across the organizations it is linked to. Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * [Keycloak] Accept invitations through brokers with Keycloak's own step Keycloak 26.8 keeps an organization invitation across the redirect to an identity provider and has idp-add-organization-member accept it, whichever provider the invitee used (keycloak/keycloak#52183). The xata capture and accept authenticators existed only to do that, so the flows stop calling them. The providers stay in the image for now. Keycloak cannot list the executions of a flow that names a provider it does not have, and keycloak-config-cli reads them before it rewrites the flow, so an image without the providers fails the realm import that would have removed them. They go in a follow-up. Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * [SSO] Route providers through Keycloak 26.8 organization domains Keycloak 26.8 keeps an organization's SSO routing on each domain, as identityProviderAlias and autoRedirect, instead of in identity provider config (keycloak/keycloak#52401). Its migration moves kc.org.domain and the redirect-on-email-match flag across and deletes them, and every later write of an organization-linked provider strips them again. The SSO service still read and wrote those keys, so after the upgrade every provider would show no domain and no enforcement, and turning enforcement on would silently do nothing. Read a provider's domain and enforcement from the domain routed to it, and write routing through SetOrganizationDomains: CreateProvider routes the domain once the provider is linked (Keycloak refuses a provider the organization is not linked to), SetProviderEnforcement flips autoRedirect, and credential rotation no longer carries routing because Keycloak leaves it in place. Revoking a lapsed domain now unverifies and unroutes it in one write, which removes the ordering the separate provider update needed. Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * [Keycloak] Trust SSO emails on verified domains and refuse unrouted providers Keycloak 26.8 takes a brokered email's verified state from the provider's email_verified claim and reads a missing one as false (keycloak/keycloak#50699), even with trustEmail. Entra's userinfo never sends the claim, so its users would be asked to verify an address their organization already controls. xata-trust-domain-email, in post broker login, marks the email verified when an organization's own provider asserted it on a verified domain routed to that provider. The organization proved it controls the domain's DNS, and with it the mail, so a verification mail would prove nothing more. It leaves the email alone when it was changed on the review page, when it is not what this login asserted, and for shared providers. xata-require-domain-sso also stops treating an organization's provider that no domain routes to as shared. That is what the domain recheck leaves once a domain lapses, and it could otherwise assert any address. Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * Trim comments Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * [SSO] Rely on Keycloak 26.8 to keep a domain to one organization Keycloak 26.8 adds a unique constraint on an organization domain's realm and name. Two organizations verifying the same domain at once no longer both succeed: the loser's update is rejected with 409, which a local run confirmed across repeated concurrent claims. Before, uniqueness was checked in application code only, so verification wrote the domain, listed every holder, and backed itself out when it found another. Map the 409 to ErrDomainAlreadyClaimed and let VerifyDomain return ErrDomainClaimedElsewhere from it directly. That drops backOutIfHeldElsewhere, the playbook section for recovering a domain held by two organizations, and OrganizationsForDomain's list of holders, which is now OrganizationForDomain. Also: - CreateProvider and DeleteDomain read the provider off the domain's routing instead of listing every identity provider. - SetOrganizationDomains matches Keycloak's one wording for each rejection. - autoRedirect is always sent; identityProviderAlias stays omitted when unset, since 26.8 rejects an empty alias. Claude-Session: https://claude.ai/code/session_01RvN9oeQKKP4e5H5TvnNa6h * Disable SSO enforcement through domain routing in the admin gate test Main added the test against redirect-on-email-match provider config, which Keycloak 26.8 replaces with org domain autoRedirect. * Keep SSO-brokered organization members managed on Keycloak 26.8 Keycloak 26.8 moves membership config onto each organization and identity provider link. The link POST takes only the provider alias and creates the link with autoMembership=true and membershipType=UNMANAGED, while links that exist at upgrade time are migrated to MANAGED. Organizations that set up SSO after the upgrade would therefore get unmanaged members, whose accounts survive removal from the organization, unlike every SSO member today. Set the link to autoMembership=true and MANAGED right after linking, including when the link already exists, so every organization keeps the behaviour it has on 26.7. * Make every organization member unmanaged Keycloak deletes a managed member's account when they are removed from the organization or the organization is deleted. An account can belong to other organizations and outlive any one of them, so no member should be managed. Drop the PUT that set SSO links to MANAGED after linking. The link POST already creates them with autoMembership=true and UNMANAGED, so the PUT has nothing left to do for new links, and depending only on the POST keeps SSO setup working against a Keycloak that predates the per-link endpoint. Links that the 26.8 migration turns MANAGED are fixed once by a separate tool. Keycloak adds an invitee who registers through the invitation link as a managed member. Have the invitation role listener make them unmanaged after the join commits, in its own transaction so a failure there is logged and cannot stop the role grant. * [SSO] Fix the merged SSO tests for domain routing * [SSO] Describe enforcement on 26.8 domain routing in the lockout playbook * [SSO] Leave a provider being created alone in the domain recheck The recheck disabled any enabled provider no domain routed to, but CreateProvider links a provider before routing its domain to it, so a recheck landing between the two switched off a provider the create then reported as working. Disable only providers whose domain is no longer verified. Re-verify now routes before enabling, so a failure between the two leaves the provider off. * [SSO] Name the provider when enforcing one no domain routes to Enforcing a provider whose domain the recheck revoked answered "domain is not verified" with no domain, since none routes to it. Answer with ErrProviderUnbound as UpdateProvider does, and say in the broker log that the provider is outside every domain routed to it. * [SSO] Expect the unbound error when enforcing an unrouted provider * [Keycloak] Vendor the 26.8.0 operator manifest and CRDs Regenerated from keycloak-k8s-resources 26.8.0 rather than editing the version strings: the operator moves to Quarkus 3.40.1 and sets a 10s termination grace period, and the realm import CRD gains organization links and per-domain routing. Our namespace templating, kube-linter annotations, enableServiceLinks and tolerations are reapplied. * [Keycloak] Turn off SCIM and block cluster node registration Keycloak 26.8 turns the SCIM API on by default, and we don't use it, so disable it at build time and in the Keycloak CR together. 26.8 also adds an executor for the legacy register-node endpoint, which otherwise lets a confidential client point management callbacks at any host; add it to the SSRF profile with no allowed hostnames, since nothing registers nodes. * [Keycloak] Hold the realm import until Keycloak runs the current spec Flux applies the Keycloak CR and the import-keycloak-realm Job together when the image changes. The operator takes a while to replace the pods (update compatibility Job, then a recreate or rolling update), and in that window the old Keycloak still answers, so keycloak-config-cli's availability check passes and it imports the new realm.json into the old version. On the 26.8 upgrade that fails on authenticators the old image lacks, or applies part of the realm before the pod goes away. Add a wait-for-keycloak init container that polls until the Keycloak CR's Ready condition is True at its current generation and the StatefulSet has rolled out that spec: observed its own generation, current revision equals update revision, every instance ready, and the keycloak container image equals the CR image. Ready and observedGeneration alone are not enough: the operator computes status from the StatefulSet it read before reconciling, so after deciding an update it reports Ready=True at the new generation while the StatefulSet is only now being scaled down or rolled. The image and rollout checks close that window. When only realm.json changes the CR and StatefulSet are already settled and the wait passes on its first poll. The init container reuses alpine/k8s, pinned by digest, under a dedicated ServiceAccount allowed to get only the auth-keycloak Keycloak and StatefulSet. realmImport.waitForKeycloak.timeoutSeconds bounds the wait. * [Keycloak] Hold the realm import until Keycloak runs the current spec Flux applies the Keycloak CR and the import-keycloak-realm Job together when the image changes. The operator takes a while to replace the pods (update compatibility Job, then a recreate or rolling update), and in that window the old Keycloak still answers, so keycloak-config-cli's availability check passes and it imports the new realm.json into the old version. On the 26.8 upgrade that fails on authenticators the old image lacks, or applies part of the realm before the pod goes away. Add a wait-for-keycloak init container that polls until the Keycloak CR's Ready condition is True at its current generation and the StatefulSet has rolled out that spec: observed its own generation, current revision equals update revision, every instance ready, and the keycloak container image equals the CR image. Ready and observedGeneration alone are not enough: the operator computes status from the StatefulSet it read before reconciling, so after deciding an update it reports Ready=True at the new generation while the StatefulSet is only now being scaled down or rolled. The image and rollout checks close that window. When only realm.json changes the CR and StatefulSet are already settled and the wait passes on its first poll. The init container reuses alpine/k8s, pinned by digest, under a dedicated ServiceAccount allowed to get only the auth-keycloak Keycloak and StatefulSet. realmImport.waitForKeycloak.timeoutSeconds bounds the wait. * [Keycloak] Bind the realm import to the intended chart revision * [Keycloak] Move invitation membership protection to the migration PR * [SSO] Defer domain uniqueness cleanup until after the upgrade * [Keycloak] Test realm import deployment ordering * Test realm import readiness in CI and bound API requests * Refresh domain ownership before disabling SSO providers * Use existing chart tooling for realm import regression tests * Replace the import polling guard with an explicit two-stage upgrade * Keep upstream SCIM feature defaults without enabling it for the realm * Separate brokered email trust from the Keycloak compatibility upgrade * Defer the built-in invitation flow switch to the invitation rollout * Document validation gates for the narrower upgrade boundary * Remove the Keycloak upgrade playbook
xata-bot
pushed a commit
to xataio/xata
that referenced
this pull request
Oct 8, 2026
* [Keycloak] Remove the organization invitation authenticators No flow calls xata-capture-org-invitation or xata-accept-org-invitation any more: Keycloak 26.8 accepts an invitation through a broker itself (keycloak/keycloak#52183). Deploy only after the flows change is live, since a realm import against an image without these providers fails while the flows still name them. OrgInvitationTokenHandler stays until keycloak/keycloak#52397 is released. * [Keycloak] Drop the invitation token handler now that 26.8 sets the organization Keycloak 26.8 includes keycloak/keycloak#52397, which puts the inviting organization on the request context in handleToken as well, so the confirm-membership page gets org without our override.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #52181
The organization from an invitation was only ever on the request context, so it was gone by the time the invitee came back from the broker. This pins it to the authentication session when the session is created, carries it across
resetFlowalongside the notes already preserved there, and letsIdpAddOrganizationMemberAuthenticatoraccept a pending invitation for the user's email as authorization on its own.Matching on the invitation email is what keeps this safe: opening an invitation and then authenticating as somebody else finds no invitation and falls through to the existing broker check.
Membership is added as unmanaged, matching
InviteOrgActionTokenHandlerrather than the registration form. Happy to switch it if you would rather the two invitation paths agree the other way.This does not cover an invitee who is already federated with the broker, since first broker login does not run for them. That looks like it belongs with #48912.
The new test uses "Back to Login" to reach the broker because
register.ftlrenders no broker buttons. It passes with the change and fails without it.I used an AI agent while working on this change.