Summary (one line)
When using Authentik as IdP for Kimai SAML SSO, both linking existing users and provisioning new users fail with Failed creating or hydrating user / AuthenticationException. Attribute mappings sometimes send literal schema URIs (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name) instead of actual values.

Full problem description

I integrated Authentik (IdP) with Kimai (SP) using SAML. Problems observed:

Two distinct failure modes (both produce the same exception):

1. Existing local user (linking failure)

   • Scenario: a user already exists in Kimai (created earlier by local sign-up or import).

   • Behavior: SAML login fails with Kimai logs showing:

     app.ERROR: Validation Failed
     security.INFO: Authenticator failed. ... Failed creating or hydrating user "<email>": Validation Failed at /opt/kimai/src/Saml/SamlProvider.php:56
     

     or

     Symfony\Component\Security\Core\Exception\AuthenticationException: Failed creating or hydrating user
     

   • Workaround observed: delete the local Kimai user; then log in via SAML — Kimai creates a fresh user from the assertion and authentication succeeds.
     Admin-created user workaround: Deleting the user and having an administrator create a new user (with the desired username/email) before trying SSO will often allow authentication to succeed, but this is inconsistent — sometimes the admin-created account works for SSO, and sometimes it still fails with the same exception. This inconsistency makes the workaround unreliable in production.

   • Impact: cannot safely migrate existing users to SAML; admins must delete or re-create users (risking data/link loss) to allow SSO.

2. New user provisioning failure (inconsistent)

   • Scenario: user does not exist in Kimai and should be auto-provisioned.
   • Behavior: Kimai throws the same Failed creating or hydrating user / AuthenticationException and does not create the account.
   • Result: SSO is unreliable for onboarding new users.

Additional symptom — attribute-as-URI:

• In some assertions or in the UI the attribute values are the literal schema URIs (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name) instead of the user’s name.
• Root cause observed: putting the URI into Authentik’s Expression field or not attaching property mappings to the provider. Even after fixing, mapping attachment/propagation sometimes appears inconsistent.

Other note: earlier Signature validation failed errors occurred until IdP cert was added to Kimai; included for context.

Logs (representative)

Kimai:

[2025-09-02T07:59:24.001139+00:00] app.ERROR: Validation Failed [] {"channel":"app"}
[2025-09-02T07:59:24.001371+00:00] security.INFO: Authenticator failed. {"exception":"... Failed creating or hydrating user \"hashim******@.gmail\": Validation Failed at /opt/kimai/src/Saml/SamlProvider.php:56)","authenticator":"App\\Saml\\SamlAuthenticator"} {"channel":"security"}

Earlier:

app.CRITICAL: SAML login failed: Signature validation failed. SAML Response rejected

Authentik test output example:

{
  "username": "muhammad.hashim",
  "pk": 21,
  "email": "muhammad.hashim*****@gmail.com"
}

Config snippets

Kimai local.yaml (example):

kimai:
  saml:
    activate: true
    title: "Login with Authentik"
    provider: true
    mapping:
      - { saml: "http://schemas.goauthentik.io/2021/02/saml/username", kimai: username }
      - { saml: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", kimai: email }
      - { saml: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", kimai: alias }
    roles:
      attribute: "http://schemas.xmlsoap.org/claims/Group"
      mapping:
        - { saml: "authentik Admins", kimai: ROLE_ADMIN }

Authentik — SAML Provider Property Mappings (exact):

• Username mapping
  SAML Attribute Name: http://schemas.goauthentik.io/2021/02/saml/username
  Expression:

  return request.user.username

• Email mapping
  SAML Attribute Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  Expression:

  return request.user.email

• Display name mapping
  SAML Attribute Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
  Expression:

  return request.user.name

Authentik provider settings:

• NameID Property Mapping → set to the email mapping (or expression return request.user.email .)
• Ensure the three property mappings are attached to the Kimai SAML provider.
• If using signed responses, ensure x509cert from Authentik is in Kimai config.

What I tried (summary)

• Corrected Authentik mapping expressions and re-tested (Test Property Mapping).
• Attached correct mappings to the SAML provider.
• Set NameID mapping to return request.user.username.
• Added IdP certificate to Kimai to fix signature validation errors.
• Cleared Kimai cache (php bin/console cache:clear) and tested in incognito.
• Captured and decoded SAMLResponse (via DevTools) to inspect <NameID> and <AttributeStatement>.
• Verified Kimai DB for existing user rows and experimented by renaming/deleting the local user (deleting makes SSO succeed — indicates conflict on linking or validation rules).
• Observed that admin-created user before SSO sometimes succeeds, sometimes still fails.

Important operational question (please answer explicitly):

We have a lot of existing employee data in Kimai. Can we sync existing local Kimai accounts to SAML identities so users keep their current Kimai accounts (names, emails, timesheets, project links) and do not need to be deleted or re-created? If yes, provide the exact, safe procedure (preferred: an idempotent SQL migration or admin UI steps) including: