Issue with Custom Attribute IDP Linking - email attribute not matching LDAP user

102 views
Skip to first unread message

Quentin Montessuis

unread,
Aug 6, 2025, 12:54:21 PMAug 6
to Keycloak User

Hello everyone,

I'm currently trying to set up automatic linking between a Google Workspace IdP and LDAP-federated users in Keycloak, using the Custom Attribute IDP Linking SPI.

The goal is to match external users logging in via Google OIDC with existing LDAP users based on the email attribute.

Here is the current setup:

  • LDAP User Federation is enabled and correctly imports the email field from Active Directory.

  • Google Identity Provider is configured with Attribute Importer mappers (email, given_name, family_name).

  • The Custom Attribute IDP Linking authenticator is placed at the beginning of the First Broker Login flow.

    • Identity provider user attribute: email

    • Lookup attribute: email

    • Fail on no match: ON

The email attribute is visible on both sides and seems to match correctly (us...@example.com for instance).

However, when a user logs in via Google, the linking fails and the logs show:

IDENTITY_PROVIDER_FIRST_LOGIN_ERROR error="invalid_user_credentials" identity_provider_identity="us...@example.com"

Despite the email attribute being set and mapped properly, Keycloak does not detect any duplication and refuses the login, attempting to trigger the first login flow but eventually throwing AuthenticationFlowException.

I’ve verified:

  • The LDAP user has the correct email field populated.

  • The IdP mappers are correctly importing the email.

  • There is no user duplication.

  • The authenticator is placed before any create-or-update logic.

Has anyone successfully used this custom SPI to link users based on email, or encountered a similar issue?

This is the current configuration in place, but I’ve tried many others, including setups without the external plugin Custom Attribute IDP Linking SPI , and I still get the same error message.

The goal here is to automatically link a Google account that shares the same email address as a federated LDAP account, so that users can log in seamlessly using their Google account with Google 2FA, which is simpler than using their usual LDAP credentials.

Any help or guidance would be highly appreciated.

Best regards,

Quentin M., Stim Studio (FR)

John Kohl

unread,
Aug 6, 2025, 1:40:46 PMAug 6
to Quentin Montessuis, Keycloak User
I've done something very similar in my realm, but I used a different custom flow.  I named it "Auto Link no create".  It's a basic flow with two steps:

Detect existing broker user (Required)
Automatically set existing user (Required)

The first time a user logs in using the identity provider, this flow looks for an existing user in the realm that has a matching email address to the SSO identity. If found, the user account is linked and the user gets access. If not found, the user is blocked with a message that their email address doesn't match a known user.

Then I set the IdP to use this flow, in the "First login flow override" setting.

Users then can either login using the IdP and its authentication mechanism, or login as a Keycloak user using the (federated) LDAP username and password.

--

Regards,

John Kohl

Senior Software Architect

signature_2709624078

hcl-software.com 


signature_416547303



--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/keycloak-user/2cb1eb2b-5d87-4b85-bf1b-82ec0dc96c07n%40googlegroups.com.

Quentin Montessuis

unread,
Aug 7, 2025, 11:30:10 AMAug 7
to John Kohl, Keycloak User

Hello John,

Thank you for your response!
Indeed, "Detect existing broker user" was the solution to my problem. I had been struggling with "Create user if unique," which was performing the existence check. The most advanced version I managed to get was working fine for auto-linking after many tests, but non-existent accounts were still being created, without privileges, but they still ended up in the database nonetheless.

Your version works perfectly and returns an error message for unknown users, exactly what I was trying to achieve!

Wishing you a great day.
Best regards,


Quentin MONTESSUIS

IT Engineer



stimstudio.com

       


Reply all
Reply to author
Forward
0 new messages