Add default claims policies for id_token

[asithade]

Added default claims policies for id_token in values.yaml.

[coderabbitai]

Walkthrough

Adds a default Authelia OIDC claims policy mapping four ID token claims and references that policy from the lfx OIDC client in the Helm values file.

Changes

Cohort / File(s)	Summary
Authelia OIDC values charts/lfx-platform/values.yaml	Adds claims_policies.default.id_token under authelia.identity_providers.oidc.jwks with claims: email, email_verified, name, preferred_username; adds claims_policy: default to the lfx client definition.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Review focus: charts/lfx-platform/values.yaml — ensure YAML structure and indentation for claims_policies and the claims_policy client reference.

Possibly related PRs

• add lfx client for authelia #39: Introduces the initial lfx client configuration in the same values file, which this PR extends with a claims policy reference.

Pre-merge checks and finishing touches

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The pull request title 'Add default claims policies for id_token' directly and clearly summarizes the main change in the changeset. The title accurately reflects that default claims policies for id_token are being added to the configuration file, which is the primary purpose of this PR.
Description check	✅ Passed	The pull request description 'Added default claims policies for id_token in values.yaml' is directly related to the changeset. It provides a brief but accurate description of what was modified (the values.yaml file) and what was added (default claims policies for id_token), which aligns with the actual changes shown in the raw summary.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/auhelia-id-claims

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 69dc354 and 3e8987d.

📒 Files selected for processing (1)

• charts/lfx-platform/values.yaml (2 hunks)

🔇 Additional comments (2)

charts/lfx-platform/values.yaml (2)

411-417: Claims policy definition looks good.

The four standard OIDC claims (email, email_verified, name, preferred_username) are appropriate for an id_token. The YAML structure is correct, with claims_policies properly positioned as a sibling to jwks under the oidc section.

---

459-479: Policy reference applied to lfx client; consider other clients.

The claims_policy: default reference is correctly applied to the lfx client, which requests openid and profile scopes. However, the docs client (line 480–499) explicitly includes id_token in its response_types, and token_helper (lines 443–458) also requests openid scope. Both could potentially benefit from referencing the same claims policy.

Is this intentional (i.e., only lfx should use the policy), or should docs and token_helper also reference it in a separate change?

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull Request Overview

This PR adds default claims policies for OpenID Connect (OIDC) id_tokens in the Authelia configuration. The changes configure which user claims will be included in id_tokens by default and apply this policy to the Heimdall client.

• Added a default claims policy specifying standard OIDC claims (email, email_verified, name, preferred_username) to be included in id_tokens
• Applied the default claims policy to the Heimdall client
• Added a new scope update:current_user_metadata to the Heimdall client's allowed scopes

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[emsearcy]

Adding claims_policy to make these claims be in the ID token, instead of only in userinfo, looks good, but adding Management API scopes doesn't make sense to me.