[alghanim]

OIDC relying parties build a user's first and last name from the standard profile claims given_name and family_name. SimpleAuth only sends name, so clients guess. OpenProject, for example, puts the whole display name into the first name and stops every new user at a registration form to type a last name. The result is accounts like "John Doe Doe".

AD already has the data, in givenName and sn. This PR carries it through.

Change

• LDAP mapping. given_name_attr / family_name_attr are added next to the existing *_attr fields. Left empty, they default to givenName / sn at runtime, so configurations saved before this change start emitting the names without reconfiguration. Both auto-configuration paths (discover and AD setup) set them explicitly. Directories without those attributes simply produce no names.
• User record. given_name / family_name are JSON fields in both stores, so no migration is needed. They are set at JIT provisioning (password login, Kerberos, admin import) and refreshed by syncUserFromLDAP on every login, exactly like department and job_title. A renamed AD account is picked up at the user's next login.
• Claims. The ID token, the access token (direct login, refresh, and the OIDC token paths) and OIDC /userinfo include given_name / family_name when known. They are omitted otherwise, for example for local users, rather than sent empty. Discovery lists both in claims_supported.
• Admin. The LDAP test-user preview shows the mapped values, so an admin can check the mapping.
• Docs. The ACTIVE-DIRECTORY.md attribute table and the API.md discovery and userinfo examples are updated.

The diff adds lines only, apart from the two lists it extends: the LDAP search attribute list and claims_supported.

Verification

Tests:

• internal/handler/oidc_profile_names_test.go runs the full authorize → code → token flow. It checks:
  • the names appear in the ID token, the access token and /userinfo (with an Arabic name);
  • they're omitted for a user without names;
  • discovery advertises both;
  • the config defaults to givenName/sn and honours an override;
  • syncUserFromLDAP stores and refreshes the names.
• internal/auth/ldap_names_test.go checks that the search requests the attributes, that the entry maps to GivenName/FamilyName, and that unmapped attributes produce nothing.

Full go test ./... is green, and go vet and gofmt are clean.

End to end: OpenProject 17.9 using SimpleAuth as its OIDC provider, against a Samba AD DC:

	before	after
first SSO login of a new AD user (newhire, Kerberos)	registration form asking for a last name, account "New Hire Hire"	straight in, account "New Hire"
existing account created before the change (jdoe)	"John Doe Doe"	corrected to "John Doe" on the next login (OpenProject refreshes names from the claims)
Arabic AD account (salem)		given_name: سالم, family_name: المري

Not in this PR

The typed SDK user models (Go, Python, JS, .NET) don't expose the two fields yet. Apps reading raw claims get them now. Adding them to each SDK is a natural follow-up, done separately so each SDK can be built and tested in its own toolchain.

This PR is independent of #72 and #73; all three merge together cleanly.

🤖 Generated with Claude Code