Restrict UI OIDC login to users with a specific group/role claim (authorization, not just authentication)

Is your feature request related to a problem? Please describe.

We deploy the self-hosted Temporal Web UI behind Entra ID (Azure AD) OIDC using the built-in UI server auth (TEMPORAL_AUTH_ENABLED=true, TEMPORAL_AUTH_TYPE=oidc, etc.). This works for authentication — but it does no authorization at the UI login layer.

The problem: once OIDC is enabled, any user in the tenant who can complete the OIDC flow gets into the UI. There is no built-in way to say "only let users who carry a specific group/role claim (e.g. an Entra group like myApp-Admin) sign in."

In our app's own portal we gate admin features on exactly this group claim, and we'd like the Temporal UI — which we link to from that portal — to enforce the same rule. Today the UI is effectively open to the whole tenant, which is a real exposure for an externally reachable UI.

Describe the solution you'd like

Native group/role allowlist on the UI OIDC config. A configuration knob on the UI server that, after the OIDC token is validated, checks a configurable claim (e.g. groups, roles, or a custom claim path) against an allowlist and rejects the login if the required value is absent.

Describe alternatives you've considered

Expose the decoded token claims so an operator can implement their own filtering. If a native allowlist is out of scope, exposing the validated OIDC claims (groups/roles/etc.) — e.g. via the session, a header to a reverse proxy, or a documented hook — would let us enforce the group check ourselves instead of leaving the UI open to the whole tenant.

Additional context

• Provider: Entra ID (Azure AD), OIDC via the UI server's built-in TEMPORAL_AUTH_* configuration.
• The group claim we want to gate on is already issued in our ID tokens (Entra group claim).
• Use case: the UI is externally exposed and linked from an admin portal; we want UI login limited to the same admin group that gates the portal, rather than the entire tenant.

Start by locating the UI server's OIDC configuration and login flow referenced by TEMPORAL_AUTH_ENABLED and TEMPORAL_AUTH_TYPE=oidc, then trace where validated token claims are available. Done means a configurable claim and allowlist can reject users whose group or role claim lacks an allowed value, with the behavior documented and tested.