Honor explicit username mapper over email-as-username during first-broker-login - #50429
Open
gaurav0107 wants to merge 1 commit into
Open
gaurav0107 wants to merge 1 commit into
gaurav0107 wants to merge 1 commit into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes a first-broker-login inconsistency where a configured UsernameTemplateMapper was overridden by the realm-level Email as username setting, causing brokered users to be created with their email instead of the mapped username.
Changes:
- Update
IdpCreateUserIfUniqueAuthenticator#getUsernameto honor the already-resolvedBrokeredIdentityContext.modelUsernameand only fall back to email-as-username whenmodelUsernameisnull. - Add a regression test ensuring
UsernameTemplateMappertakes precedence even whenregistrationEmailAsUsernameis enabled.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| services/src/main/java/org/keycloak/authentication/authenticators/broker/IdpCreateUserIfUniqueAuthenticator.java | Stops re-deriving/clobbering the brokered username so mapper-provided modelUsername wins over email-as-username. |
| testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/broker/UsernameTemplateMapperTest.java | Adds a regression test covering mapper precedence when registrationEmailAsUsername is enabled. |
…oker-login When a realm has "Email as username" enabled, IdpCreateUserIfUniqueAuthenticator ignored a username supplied by an identity-provider UsernameTemplateMapper and used the email instead. IdentityBrokerService already resolves the username with the correct precedence (mapper value first, email as fallback), so honor that resolved modelUsername in the authenticator rather than re-applying the email-as-username rule unconditionally. Closes keycloak#49300 Signed-off-by: gaurav0107 <gauravdubey0107@gmail.com>
gaurav0107
force-pushed
the
fix/49300-usernametemplatemapper-is-overridden-by
branch
from
July 3, 2026 18:18
8d45bef to
741c825
Compare
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 #49300
Summary
When a realm has Email as username (
registrationEmailAsUsername) enabled,an explicitly configured identity-provider
UsernameTemplateMapperwas silentlyignored during first-broker-login: the brokered user's username was set to the
email instead of the mapped value.
The root cause is an inconsistency between two code paths:
IdentityBrokerServicealready resolves the username with the correctprecedence — it keeps the mapper-provided
modelUsernamewhen present and onlyfalls back to the email (when email-as-username is enabled) if no mapper set a
username.
IdpCreateUserIfUniqueAuthenticator#getUsernamethen re-derived the usernamewith
realm.isRegistrationEmailAsUsername() ? brokerContext.getEmail() : brokerContext.getModelUsername(), unconditionally preferring the email andclobbering the already-resolved value.
This change makes the authenticator honor the resolved
modelUsernameand fallback to the existing email-as-username behavior only when it is
null. The fixis also inherited by
IdpDetectExistingBrokerUserAuthenticator. Realms without ausername mapper are unaffected:
modelUsernamealready equals the email in thatcase, so the behavior is unchanged.
Testing
Added
usernameTemplateMapperShouldTakePrecedenceOverEmailAsUsernametoUsernameTemplateMapperTest, which enablesregistrationEmailAsUsernameon theconsumer realm, performs first-broker-login, and asserts the created user's
username equals the mapper template result (
${ALIAS}_${CLAIM.sub}) rather thanthe email.
Note on tooling
This contribution was prepared with the assistance of an AI coding agent. I have
reviewed and understand every change, and I am able to explain and revise it in
response to review feedback.