Enable editing of custom claims for keycloak provider

[rak-phillip]

Summary

This enables the editing of custom claims for keycloak provider.

Fixes #16241

Occurred changes and/or fixed issues

• Enable editing of custom claims for keycloak provider
• Add unit tests to assert new behavior

Technical notes summary

rancher/rancher#53465 contains fixes for custom userName claims in keycloak. This change requires that custom claims be enabled for keycloak as well as generic oidc.

Areas or cases that should be tested

Keycloak OIDC should render and save custom claims

Areas which could experience regressions

This change should be additive to the keycloak provider config form.

Screenshot/Video

Checklist

• The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
• The PR has a Milestone
• The PR template has been filled out
• The PR has been self reviewed
• The PR has a reviewer assigned
• The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
• The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes
• The PR has been reviewed in terms of Accessibility
• The PR has considered, and if applicable tested with, the three Global Roles Admin, Standard User and User Base

[aalves08]

Overall, the functionality and interaction with backend seems to work just fine. Data is being persisted on the backend and if we clear the checkbox on the UI, data is cleared on the backend as expected.

3 comments:

• should we surface the claims info on the non-edit screen?
• should we validate the email field (we probably have it somewhere in our code...)?
• if we "add custom claims" (check the checkbox) are any of the fields required? right now the form reacts as none being required

[rak-phillip]

should we surface the claims info on the non-edit screen?

I don't think we should change this. The scope of the change is to surface existing behavior for keycloak.

should we validate the email field (we probably have it somewhere in our code...)?

If the ask is to treat this field as an email address, no. The custom claim would be something like user_email instead of email.

if we "add custom claims" (check the checkbox) are any of the fields required? right now the form reacts as none being required

I don't believe so. Custom claims are for manually mapping when a provider doesn't use standard claims in a token. There's no guarantee that we will need to map all three currently represented.

[aalves08]

Given the replies, 👍