fix: move keycloak group client-role assignments to 05-group-roles.yaml

[hakan-persson]

Copies the regenerated 45-keycloak-config-configmap.yaml from the j26-keycloak source repo (commit f8098ae) into the prod manifests.

Move group→client-role assignments to 05-group-roles.yaml

config-cli imports files alphabetically. A group’s clientRoles assignment needs the referenced client role to already exist — those roles are defined in 04-clients.yaml, so the assignments must run after it. Keeping them in 01-realm.yaml (imported 2nd) works in steady state but fails a fresh-realm rebuild with role-not-found. The new 05-group-roles.yaml imports last; the group structure stays in 01-realm.yaml.

Verified live in j26-prod

Applied manually via kubectl and tested before this PR:

• config-cli imports all 6 files clean (00→05), no errors.
• Role assignments present: j26-scoutid-sync → j26-booking:bookings:self:create, planning-staff → j26-signupinfo:summaries:read.
• Sync-owned group subtree intact — 857 total groups (577 kår + 242 villages) unchanged before and after, so the 05 group re-declaration + IMPORT_MANAGED_GROUP=no-delete did not prune.
• Auth works (token issuance OK), Keycloak healthy.

Scope note — username validator removal dropped

This PR previously also removed the up-username-not-idn-homograph username validator, on the theory that the pipe in scoutnet|<id> tripped it. That was wrong — tested and disproved: with the validator active, kcadm created scoutnet|999999-zz-claudetest without error. That change has been reverted in the source repo and dropped here, so this PR is now only the ordering fix and does not touch the validator.

The real cause of error-username-invalid-character on user:3222778 is still unidentified. It’s currently dormant — the validator only runs when Keycloak writes a user profile, and the syncs are clean with Users created: 0.

Note on urgency

The fix is applied live but not durable: j26-keycloak-scoutid-prod has automated: true, so any commit landing on main (even unrelated) triggers an auto-sync that re-applies main’s configmap and wipes it. This already happened once. Merging this is what makes it stick.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the production Keycloak config-cli ConfigMap for j26-keycloak-scoutid to match the regenerated upstream configuration, addressing a username validation failure for Scoutnet-style usernames and making group→client-role imports deterministic on fresh realm bootstrap.

Changes:

• Removes the up-username-not-idn-homograph username validator so scoutnet|<id> usernames no longer fail validation.
• Moves group→client-role assignments out of 01-realm.yaml into a new 05-group-roles.yaml so they import after 04-clients.yaml (roles exist before assignment).
• Adds/updates inline comments documenting the import-order dependency and managed-group behavior assumptions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[scriptcoded]

Just double checking. Have you verified that it's up-username-not-idn-homograph that's causing the issue? Previously it was username-prohibited-characters, but I can see that's not in the config either.

[hakan-persson]

You were right to be unsure — I tested it, and my diagnosis was wrong. The username validator is not the cause, so I'm dropping that half of this PR.

The test

The up-username-not-idn-homograph validator is currently active on the prod realm (it came back when an automated sync re-applied main's configmap). With it active, I created a user with a real-format username via kcadm:

$ kcadm create users -r jamboree26 -s 'username=scoutnet|999999-zz-claudetest' -s enabled=true
Created new user with id '5ddba982-...'      # ← accepted, no error

The pipe does not trip that validator. (Test user deleted afterwards.) The real user scoutnet|3222778 also exists and is enabled: true in the realm, so it was created successfully at some point too.

I had inferred the mechanism from the config — pipe + a homograph/mixed-script guard sounded like a match — instead of reproducing it. That was my mistake, and removing the validator would have been a prod auth change made on a wrong hypothesis.

What's still unknown

The actual cause of error-username-invalid-character on user:3222778 isn't identified. Worth noting the syncs are currently clean — both staff (1560/1560) and participants (16781/16781) complete with Users created: 0 and zero username errors. The validator only runs when Keycloak writes a user profile, so with no new users being created it's dormant regardless. Whatever produced the original error may have been specific to that user's data at that moment.

What I'm doing with this PR

Splitting it: keeping the 05-group-roles.yaml ordering fix (that one I verified empirically — a fresh-realm import fails at 01-realm.yaml with role-not-found; the 05 split fixes it; and I confirmed the sync-owned group subtree is untouched, 857 groups / 577 kår / 242 villages before and after). Dropping the validator removal — no evidence supports it.

Pushing the reduced version to this branch shortly.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.