mbp-1043: Client Assertion based authentication using Entra ID

[mlorenzofr]

Summary

• Add client assertion authentication support for Azure Entra ID in qtodo
• Refactor qtodo Helm chart to support multiple OIDC providers (keycloak and entraid) with provider-specific configuration
• Add automation scripts for Entra ID setup for qtodo, RHTPA, and RHTAS
• Update documentation with Entra ID integration guide

Changes

Helm templates and helpers:

• Refactor qtodo.oidc.url helper to support Entra ID tenant-specific URLs
• Refactor qtodo.jwt.audience helper to handle Entra ID audience format

Automation scripts:

• Add scripts/entraid/setup-qtodo-entraid.sh: automated qtodo app registration
• Add scripts/entraid/setup-rhtas-entraid.sh: automated RHTAS app registration
• Add scripts/entraid/setup-rhtpa-entraid.sh: automated RHTPA API and frontend app registrations
• Add scripts/entraid/cleanup-entraid.sh: cleanup script for removing Entra ID resources created by setup scripts

Feature configuration:

• Update scripts/features/entra-id.yaml with qtodo, RHTPA, and RHTAS Entra ID overrides
• Add Vault secret templates for Entra ID client credentials and tenant configuration

Chart values:

• Update charts/qtodo/values.yaml with Entra ID provider settings

Documentation:

• Expand docs/oidc/entraid.md with:
  • Architecture overview and authentication flow
  • Prerequisites (Azure subscription, permissions, az CLI)
  • Step-by-step app registration process
  • Federated credential configuration for SPIFFE workload identities
  • Values file configuration examples

Dependencies

validatedpatterns-demos/qtodo#8

Test plan

• Verify qtodo Helm chart renders correctly with Entra ID provider configuration
• Verify automation scripts create app registrations with correct federated credentials
• End-to-end authentication flow with Entra ID (pending qtodo app changes)
• Test cleanup script removes all created resources

[p-rog]

LGTM

I have only one concern related to the ACS and Entra ID federation support. Is there a reason why ACS has been removed from the scope? Users switching from Keycloak to Entra ID would lose ACS SSO.

ACS supports Entra ID integration:
https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.11/html-single/integrating/index#azure-entra-id-federation-overview_integrate-using-short-lived-tokens

[mlorenzofr]

LGTM

I have only one concern related to the ACS and Entra ID federation support. Is there a reason why ACS has been removed from the scope? Users switching from Keycloak to Entra ID would lose ACS SSO.

ACS supports Entra ID integration: https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.11/html-single/integrating/index#azure-entra-id-federation-overview_integrate-using-short-lived-tokens

Integration with Azure Entra ID was planned for the qtodo, RHTAS, and RHTPA components. ACS was not added, possibly because the component was not yet integrated into the pattern when this planning was done.

In this specific case, the feature being added is client assertion support for qtodo, which already had its integration with Azure Entra ID implemented but using a client secret.

Note that these integrations with Azure Entra ID are not intended to integrate the pattern compatible with Azure's own resources (or other cloud resources). The goal is to provide support for an additional IdP, besides RHBK, which is the default IdP included with the pattern.

[p-rog]

LGTM
I have only one concern related to the ACS and Entra ID federation support. Is there a reason why ACS has been removed from the scope? Users switching from Keycloak to Entra ID would lose ACS SSO.
ACS supports Entra ID integration: https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.11/html-single/integrating/index#azure-entra-id-federation-overview_integrate-using-short-lived-tokens

Integration with Azure Entra ID was planned for the qtodo, RHTAS, and RHTPA components. ACS was not added, possibly because the component was not yet integrated into the pattern when this planning was done.

In this specific case, the feature being added is client assertion support for qtodo, which already had its integration with Azure Entra ID implemented but using a client secret.

Note that these integrations with Azure Entra ID are not intended to integrate the pattern compatible with Azure's own resources (or other cloud resources). The goal is to provide support for an additional IdP, besides RHBK, which is the default IdP included with the pattern.

I see. Thanks for the explanation.
I can think about adding the ACS Entra ID integration as a part of making ACS independent chart.
It's not a blocker for now.