[Feature]: First-class "Identity Providers / Key Managers" resource for MCP/API authentication, instead of config.toml-only setup

[randilt]

Please select the area the issue is related to

AI Workspace, Gateway

Please select the aspect the issue is related to

Aspect/UI (Frontend layouts, components, styling), Aspect/Configuration (Config files, settings, env vars, defaults)

Suggested Feature

Securing an MCP proxy (or any resource) with an enterprise IdP requires registering a JWT key manager (issuer, JWKS URL) as a system-level parameter in the gateway's config.toml (policy_configurations.jwtauth_v0.keymanagers). There is no Console UI to register this — checked the MCP proxy's Security/Policies tabs directly, no such option is present.

This is a near-universal, first-touch setup step (any real deployment needs an IdP connected before going to production), yet it requires host/file access to the gateway rather than being doable from the Console — unlike comparable resources (LLM Providers) which are fully UI-managed. It also creates an org/team dependency: whoever configures proxies in the Console often isn't the person with gateway host access.

Suggest adding "Identity Providers" (or "Key Managers") as a first-class, UI-managed resource, following the same pattern as LLM Providers: enter an issuer URL, auto-discover JWKS/token endpoints via /.well-known/openid-configuration (AI Workspace's own admin login already does this kind of discovery, so the capability exists in the codebase), then select the registered IdP from a dropdown when attaching MCP Authentication or similar policies — instead of referencing one by name that only exists in a file the Console user may not have access to.

A "Test Connection" action against the registered JWKS endpoint at config time would also help catch typos/unreachable IdPs before relying on it in production.

Related Issues

No response

Steps to Verify

• Design Document — A detailed design document has been created and reviewed, covering architecture, data flow, and edge cases.
• Design Mail — A design summary email has been sent to relevant stakeholders for awareness and feedback.
• Code Review — All code changes have been peer-reviewed and approved according to the project's review standards.
• Testing Complete — Adequate unit, integration, and/or end-to-end tests have been written and are passing.
• Documentation Review — User-facing and/or developer documentation has been updated to reflect the new feature and reviewed.
• Feature Complete — The feature is fully implemented, all checklist items above are done, and it is ready for release.