Restructure authentication & authorization configuration

[Thushani-Jayasekera]

Restructure authentication & authorization configuration

Purpose

Authorization settings in the Platform API lived under [platform_api.auth.idp] (validation_mode, role_mappings) and [platform_api.auth] (scope_validation). That placement made role-based authorization reachable only in idp auth mode, even though a token minted by an enterprise IDP carries the same roles claim whether the platform verifies it against a JWKS endpoint or with a local public key. It also left file-mode users with no way to express grants as a role — every user needed a hand-maintained ~100-scope string.

This PR separates authentication (how a token is verified) from authorization (what a verified token may do), mirroring the split Kubernetes draws between its authn/authz configs and Envoy draws between JWT providers and rules.

Changes

New [platform_api.auth.authorization] section — validated in every auth mode, not inside any one mode's branch:

Before	After
auth.scope_validation	auth.authorization.enabled
auth.idp.validation_mode	auth.authorization.mode (scope | role)
auth.idp.role_mappings	auth.authorization.role_to_scope_mapping

The mapping setting is named role_to_scope_mapping rather than role_mappings: "mappings" alone didn't say what was mapped to what, and the file it points at is now read by both authorization modes and by file-mode login, so the direction (roles → scopes) is worth spelling out at the config key. The file itself is renamed to match — resources/roles.yaml → resources/role-to-scope-mapping.yaml — since a bare roles.yaml in a mounted config directory reads like a list of roles rather than a grant table.

Auth mode renamed external_token → internal_token. The old name suggested a third-party issuer; the mode actually verifies tokens minted by another trusted platform component holding the matching RSA private key.

File-mode users are granted roles, and only roles. auth.file.users[].scopes is gone; auth.file.users[].roles names one or more roles from the mapping file and is the user's entire grant. The login endpoint expands them into the token's scope claim and also emits the role names themselves as the roles claim — so the same token works whether authorization runs in scope or role mode. Privileges are now defined in exactly one place, so no per-user scope string can drift out of step with the roles it was meant to mirror, and the shipped admin no longer carries a ~100-scope literal.

roles is a list, not a single name. A user whose persona spans two shipped roles names both (roles = ["ap_publisher", "ap_subscriber"]) and gets the union of what they grant — most-permissive wins, duplicate scopes collapsed — rather than forcing a sixth role to be defined for the combination, or a per-user scope list to be reintroduced for it. That also matches the shape the rest of the system already uses: a token's roles claim is a list, and role authorization mode already unioned across it, so file mode was the one place a multi-role identity couldn't be expressed.

role-to-scope-mapping.yaml (formerly roles.yaml) reworked. Roles are renamed into the platform's own namespace rather than any one IDP's convention, since the same file now serves every auth mode: platform-admin → ap_admin, platform-operator → ap_operator, platform-viewer → ap_viewer. platform-developer covered both API lifecycle and application/subscription ownership, so it splits into ap_publisher (lifecycle) and ap_subscriber (own applications, subscriptions and keys). Every role gains sub-resource scopes (ap:rest_api:deployment:manage, ap:gateway:token:manage, …) and Developer Portal dp:* scopes, so one role describes a persona across the whole platform rather than only this server — which is what makes a per-user scope list unnecessary.

ValidateRoleScopeMap is now namespace-scoped. An ap: scope must be declared in the OpenAPI spec (unchanged, fail-fast at startup); a scope in another component's namespace is checked for well-formedness only — this server mints those but never enforces them, so it can neither confirm nor deny their existence. The unused ap:devportal:* and ap:git:read scopes are removed platform-wide — no spec declared them and no component enforced them (the AI Workspace's DEVPORTAL_* constants were never referenced), so the minted-scope allowlist that existed to carry them is gone too. The well-formedness check itself was tightened: segments may contain hyphens (a foreign namespace picks its own convention, e.g. dp:api-key_read) and * is accepted only as a trailing segment, not as a free-floating character. Event-gateway scopes stay commented out in the shipped file since they're only declared on a build that compiles in that plugin (-tags experimental).

Startup validation added (all fail-closed):

• auth.authorization.mode must be scope or role — rejected even when enabled = false, so flipping enforcement back on isn't what surfaces a typo.
• mode = "role" requires both claim_mappings.roles and role_to_scope_mapping. Without the mapping file, role names would be used verbatim as scope values.
• Every file-mode user must have at least one entry in roles, and no entry may be blank — a user without a usable role authenticates successfully and is then denied every request.
• File mode requires role_to_scope_mapping to be set, and every role a user names must exist in the loaded file (validateFileUserRoles) — a typo would otherwise surface as a login that succeeds and 403s on everything.

Nested claim mappings work in file mode. Every claim_mappings.* field already accepted a dot-separated path into a nested claim (realm_access.roles, the Keycloak shape) on the read side, but the login endpoint wrote flat keys — so a config using that layout signed a claim literally named realm_access.roles, which resolveClaimPath then failed to find. For the roles mapping that meant a user who logs in successfully and is then denied every request. The endpoint now writes through setClaim, the write-side mirror of resolveClaimPath: intermediate objects are created and merged into (never replaced), so mappings sharing a prefix coexist and one mapping serves both directions in whichever auth mode is active.

The config an operator writes

[auth.claim_mappings]
roles = "realm_access.roles"     # Keycloak's nested shape
organization = "org_id"

They write this because the rest of their estate (Keycloak) puts roles at realm_access.roles, and they want one mapping that works whether platform-api is running in IDP mode or file mode.

BEFORE — the login endpoint wrote flat keys

platform-api/internal/handler/auth_login.go did the equivalent of claims[name] = value, so the mapped name was used verbatim as a single key:

{
  "sub": "alice",
  "iss": "https://platform-api",
  "realm_access.roles": ["ap_admin"],   ← ONE key, literally named "realm_access.roles"
  "org_id": "acme"
}

But the read side — resolveClaimPath in platform-api/internal/middleware/auth.go:360 — splits on . and walks into nested objects:

resolveClaimPath(claims, "realm_access.roles")
  → claims["realm_access"]           // looks for a nested object
  → not found (there is no "realm_access" key, only "realm_access.roles")
  → ok = false

So: login succeeds, the user gets a token, and then every subsequent request is denied — the middleware looks for the roles claim, finds nothing, and the user has no roles/scopes. Silent, and only in file mode; the same config works fine against Keycloak.

AFTER — setClaim mirrors resolveClaimPath

setClaim (auth_login.go:193) splits the same path and builds the nested objects:

{
  "sub": "alice",
  "iss": "https://platform-api",
  "realm_access": {
    "roles": ["ap_admin"],
    "org_id": "acme"
  }
}

Now resolveClaimPath("realm_access.roles") walks claims["realm_access"]["roles"] and finds ["ap_admin"]. Same mapping, both directions.

The "merged into, never replaced" part

If the config maps two claims under the same prefix:

[auth.claim_mappings]
roles        = "realm_access.roles"
organization = "realm_access.org_id"

A naive implementation that did claims["realm_access"] = map{"org_id": ...} on the second write would blow away the first. setClaim reuses the existing intermediate map if one is already there (auth_login.go:205-209), so both survive regardless of write order — which is exactly the case auth_login_test.go:122-123 pins down.

Defaults: claim_mappings.roles now defaults to "roles" (what Asgardeo and Entra ID emit, and what the file-mode login endpoint signs), so switching to role mode needs no extra claim wiring. role_to_scope_mapping stays empty in DefaultConfig on purpose — the mapping file is operator-owned and mounted, so a built-in path would make startup depend on a file the image doesn't carry.

Packaging: role-to-scope-mapping.yaml is now mounted at /etc/platform-api/role-to-scope-mapping.yaml in every compose pack (all-in-one, AI Workspace, Developer Portal), and the two portal Makefiles copy/rewrite it into their distributions. It's mounted rather than baked into the image so operators can edit what a role grants. The shipped config.toml admin user is now just roles = ["ap_admin"]. In Helm, config.auth.file.admin.scopes is replaced by a required config.auth.file.admin.roles list, and the chart now renders config.auth.authorization.roles into its config ConfigMap and mounts it at roleToScopeMapping — so a default helm install in file mode has a mapping file without the operator wiring one up. The chart ships only ap_admin there; platform-api/resources/role-to-scope-mapping.yaml remains the full sample set to copy from.

Breaking change / migration

Existing configs must be updated. The retired keys no longer map to anything and are silently ignored, so the effective setting becomes the default (enabled = true, mode = "scope") rather than what the file says:

# before
[platform_api.auth]
scope_validation = true
[platform_api.auth.idp]
validation_mode = "role"
role_mappings   = "/etc/platform-api/roles.yaml"

# after
[platform_api.auth.authorization]
enabled                = true
mode                   = "role"
role_to_scope_mapping = "/etc/platform-api/role-to-scope-mapping.yaml"

auth.mode = "external_token" must become "internal_token"; startup fails with the mode-list error otherwise. The mapping file itself is renamed roles.yaml → role-to-scope-mapping.yaml, so a custom file needs renaming (or the path in config pointed at wherever you keep it), and one using the old platform-* role names needs those renamed too (or the role names in config updated to match).

File-mode users must be converted from a scope list to a roles list. scopes is no longer a recognized key, and a user without roles fails startup:

# before
[[platform_api.auth.file.users]]
username      = "admin"
password_hash = "$2a$12$…"
scopes        = "ap:organization:manage ap:rest_api:manage dp:org_manage …"

# after — define a role in role-to-scope-mapping.yaml granting those scopes, then name it
[[platform_api.auth.file.users]]
username      = "admin"
password_hash = "$2a$12$…"
roles         = ["ap_admin"]

roles is a list, so a user whose persona spans two shipped roles names both (roles = ["ap_publisher", "ap_subscriber"]) and gets the union of what they grant, most-permissive wins, with duplicate scopes collapsed — rather than needing a role defined for the combination.

Since roles are now the only grant, auth.authorization.role_to_scope_mapping is required in file mode even when authorization runs in the default scope mode. A leftover scopes key is ignored rather than rejected, but missing roles fails startup with a message naming the user, so a half-migrated config can't start and silently grant nothing.

Docs updated for the new shape: platform-api/README.md (RBAC section, role table, file-mode granting — including the multi-role example), both portal distribution READMEs, portals/developer-portal/README.md's local-auth example, config-template.toml, and Helm values.yaml comments.

Also corrected while in there: platform-api/README.md documented the JWT keys as public_key/private_key, but the runtime keys are public_key_file/private_key_file — a copied snippet would have been silently ignored and failed the key-required check. portals/ai-workspace/production/README.md showed [auth.authorization]/[auth.claim_mappings] without the platform_api prefix the surrounding blocks use, and portals/ai-workspace/README.md's local-override row named [auth] mode = "idp".

Testing

• New TestValidateAuthorizationConfig covering each mode, missing roles claim, missing mapping file, unknown/empty mode, and invalid-mode-while-disabled.
• New TestValidateAuthConfig_RoleAuthorizationInInternalTokenMode — asserts role authorization validates outside idp mode, the case that was previously unreachable.
• New file-mode cases: user with no roles, roles without a mapping file, roles while authorization runs in scope mode.
• New handler tests for effectiveScopes: single-role expansion, cross-namespace roles, duplicate-within-a-role dedupe, multiple roles unioning their scopes, a scope granted by two of the user's roles appearing once, unknown role grants nothing, no roles grants nothing — plus the roles claim in issued tokens.
• New TestLoadConfig_FileUserRolesList — loads the shipped roles list shape end to end and asserts {{ env }} interpolation reaches inside array elements. A regression there would hand the raw {{ env … }} string to the role lookup, and the user would silently be granted nothing rather than failing loudly.
• New role_scope_map tests for the namespace-scoped validation (foreign namespace accepted, hyphenated foreign scope accepted, non-trailing wildcard rejected, malformed scope rejected).
• TestShippedSampleRolesValidateAgainstShippedSpec covers the shipped role-to-scope-mapping.yaml against the shipped OpenAPI spec, so a pack can't ship a mapping that fails startup.
• Test fixtures converted to roles: tests/integration-e2e now mounts the shipped role-to-scope-mapping.yaml and grants ap_admin; the developer-portal IT suite gets it/configs/roles-platform-api-it.yaml with one role per account (dp_admin_it/dp_publisher_it/dp_developer_it) carrying exactly the scope sets those users had.
• Dead env plumbing removed from tests/integration-e2e. All three compose files set APIP_CP_AUTH_FILE_BASED_* variables that reach nothing: platform-api has no env-override layer, and an env var only takes effect via the {{ env }} token that names it — which the fixture toml spells APIP_CP_AUTH_FILE_ORGANIZATION_*. Renamed to the names actually read, and dropped ..._ENABLED, APIP_CP_WEBHOOK_GATEWAY_TYPE (no such config key), and the whole AUTH_FILE_BASED_USERS injection path including its os.Setenv in suite_test.go. The @devportal admin gets its dp:* scopes from ap_admin in the mounted role-to-scope-mapping.yaml, which is what was already happening.
• tests/ai-workspace-cli-e2e migrated. It was entirely pre-restructure and could not have started: no [platform_api] prefix, [auth.file_based], an HMAC secret_key, no RSA keypair, no TLS certs, no role-to-scope mapping. The toml is rewritten to the current shape and the compose now follows the integration-e2e pattern (certgen + jwtkeygen init containers, keys/certs volumes, role-to-scope-mapping.yaml mount).
• New TestSetClaimNestedPaths: flat mapping writes a top-level claim, dotted mapping writes the nested object (and leaves no literal dotted key), two mappings sharing a prefix both survive, deeper nesting creates every intermediate level.
• go build ./... and go test ./... pass in platform-api; go vet clean in both e2e suites.
• helm template renders cleanly; the chart's default ap_admin scope list was checked to be a subset of the shipped role-to-scope-mapping.yaml's, so it is covered by the spec-validation test above.

Reviewer notes

• The login route registration moved later in StartPlatformAPIServer — it now needs the loaded role→scope map, so it's registered after loadRoleScopeMap. It stays public via cfg.Auth.SkipPaths, unchanged.
• loadRoleScopeMap is no longer gated on auth mode or authorization mode; it loads whenever a path is configured. Config validation is what requires the path where it's needed.
• ValidateRoleScopeMap must run after plugin OpenAPI specs are merged, since plugin-contributed ap: scopes are validated against the registry.
• The e2e admin previously carried ap:websub_api:manage/ap:webbroker_api:manage. Those are declared only on an -tags experimental build and no CI job builds one, so they were inert; they are not in the ap_admin role and the fixtures no longer request them.
• tests/ai-workspace-cli-e2e was migrated rather than left behind (see the fixture section above). It runs daily in CI and needs Docker, so the config was brought to the current contract but the suite has not been run end to end here — worth one manual run before merging.
• The role_to_scope_mapping rename touches a lot of files but is mechanical: config key, one Go field (Authorization.RoleToScopeMapping), one Helm value (roleToScopeMapping), the filename, and every mount path/subPath/ConfigMap key that named it. The behavioural diff is confined to FileBasedUser.Roles, effectiveScopes, validateFileBasedConfig, and validateFileUserRoles.
• gateway-controller's auth.idp.role_mapping is a different setting (IDP role → local gateway role, in a separate config tree) and is deliberately left untouched by this rename. Worth a second opinion on whether the asymmetry is acceptable or whether it should follow.
• The -tags experimental build is broken on main (undefined: api.OrganizationSubscription in the event-gateway plugin), so it could not be compiled to verify the plugin's scope contribution end-to-end. Pre-existing and unrelated.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR replaces legacy external-token and IDP authorization settings with unified authorization configuration, introduces role-based file authentication and JWT claims, validates namespace-aware role mappings, mounts roles.yaml into distributions, and updates runtime wiring, tests, Helm values, and documentation.

Changes

Authorization and role-mapping migration

Layer / File(s)	Summary
Authentication and authorization contracts platform-api/config/*, kubernetes/helm/platform-api-helm-chart/*	Authentication now uses internal_token; authorization is configured through auth.authorization with scope or role modes, updated claim mappings, file-user roles, and expanded validation tests.
Role mapping validation and shipped roles platform-api/internal/middleware/*, platform-api/internal/server/role_scope_map_test.go, platform-api/resources/roles.yaml	Role mappings validate malformed scopes and enforce known ap:* scopes while accepting well-formed foreign namespaces; shipped roles and scope grants are replaced with ap_* mappings.
Runtime authorization and login flow platform-api/internal/server/server.go, platform-api/internal/handler/*, platform-api/plugins/eventgateway/plugin.go, platform-api/internal/server/scope_route_coverage_test.go	Startup loads mappings and validates file-user roles, authorization-aware handlers use the shared mode, and file login tokens combine direct and role-derived scopes while optionally adding roles claims.
Deployment packaging and configuration documentation distribution/*, portals/*, platform-api/README.md	Compose and distribution workflows mount or stage roles.yaml, while portal and Platform API documentation describe the revised authentication and authorization configuration.

Estimated code review effort: 4 (Complex) | ~60 minutes

Sequence Diagram(s)

sequenceDiagram
  participant StartPlatformAPIServer
  participant loadRoleScopeMap
  participant validateFileUserRoles
  participant AuthLoginHandler
  StartPlatformAPIServer->>loadRoleScopeMap: load configured role mappings
  loadRoleScopeMap-->>StartPlatformAPIServer: return roleScopeMap
  StartPlatformAPIServer->>validateFileUserRoles: validate configured file-user roles
  validateFileUserRoles-->>StartPlatformAPIServer: return validation result
  StartPlatformAPIServer->>AuthLoginHandler: register handler with roleScopeMap
  AuthLoginHandler-->>StartPlatformAPIServer: issue token with effective scopes and roles

Loading

Possibly related PRs

• wso2/api-platform#2812: Overlaps with server startup and event-gateway authorization wiring.
• wso2/api-platform#2814: Also changes role-scope mapping loading and validation during Platform API startup.
• wso2/api-platform#2942: Overlaps with OpenAPI scope enforcement and skip-path handling.

Suggested reviewers: renuka-fernando, lasanthas, anugayan

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 88.89% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main change: restructuring authentication and authorization configuration.
Description check	✅ Passed	The description covers purpose, major changes, migration, and testing, though explicit docs, security, samples, and test-environment sections are missing.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

portals/ai-workspace/production/README.md (1)

116-124: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Use the full [platform_api.auth.*] namespace in both production and troubleshooting documentation.

The unified configuration contract is rooted at platform_api; using absolute TOML tables under [auth...] writes settings the Platform API does not read.

• portals/ai-workspace/production/README.md#L116-L124: rename the authorization and claim-mapping tables to [platform_api.auth.authorization] and [platform_api.auth.claim_mappings].
• portals/ai-workspace/README.md#L377-L377: document the local override as [platform_api.auth] mode = "idp".

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@portals/ai-workspace/production/README.md` around lines 116 - 124, Update the
production documentation tables at
portals/ai-workspace/production/README.md:116-124 to use
[platform_api.auth.authorization] and [platform_api.auth.claim_mappings]. Also
update the local override at portals/ai-workspace/README.md:377 to document
[platform_api.auth] mode = "idp".

🧹 Nitpick comments (1)

platform-api/internal/middleware/role_scope_map.go (1)

69-95: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low value

Regex is both looser and stricter than the doc comment claims.

^[a-z0-9_]+:[a-z0-9_:*]+$ accepts * anywhere (ap:*:read, dp:***), not just as a :* tail, and rejects - entirely — so a sibling component that names a scope like dp:api-key_read would fail startup even though this server has no authority over that namespace. Consider anchoring the wildcard to the tail and deciding explicitly whether - is allowed in foreign scope names.

♻️ Tighter shape, hyphen-tolerant

-var wellFormedScope = regexp.MustCompile(`^[a-z0-9_]+:[a-z0-9_:*]+$`)
+var wellFormedScope = regexp.MustCompile(`^[a-z0-9_-]+:[a-z0-9_-]+(?::[a-z0-9_-]+)*(?::\*)?$`)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@platform-api/internal/middleware/role_scope_map.go` around lines 69 - 95,
Update wellFormedScope to enforce the documented namespace:name shape with an
optional wildcard only as a trailing :* segment, while allowing hyphens in
foreign namespace or scope names such as dp:api-key_read. Keep
ValidateRoleScopeMap’s namespace-scoped behavior unchanged: apply this syntax
check to all scopes, then validate only PlatformScopePrefix entries against the
registry.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@platform-api/config/config.go`:
- Around line 953-964: Update the file-user validation near the existing
Role/Scopes checks to reject users with Role empty and Scopes non-empty when
auth.authorization.mode is "role". Use the surrounding configuration symbols and
return the same startup-validation error style, while preserving scopes-only
users in non-role authorization modes.
- Around line 900-908: Update validateIDPConfig to reject IDP configurations
with an empty audience list, alongside the existing JWKS URL and issuer checks.
Return a startup validation error identifying auth.idp.audience, while
preserving successful validation for configurations with at least one audience.

In `@platform-api/internal/handler/auth_login.go`:
- Around line 115-121: Update the matching-role claim handling around
matched.Role and claimKey(cm.Roles, "roles") so file-mode tokens remain readable
when claim_mappings.roles is dotted, such as realm_access.roles. Either reject
dotted role mappings in file mode during configuration validation or emit the
corresponding nested claim structure; preserve the existing flat claim behavior
for non-dotted mappings.

In `@platform-api/README.md`:
- Line 9: Update the authentication documentation in the README to consistently
use the runtime configuration keys public_key_file and private_key_file instead
of public_key and private_key, including the references around internal_token
configuration. Also align the idp-mode guidance with the corresponding
references in portals/ai-workspace/distribution/README.md.

In `@platform-api/resources/roles.yaml`:
- Around line 76-97: Update ValidateRoleScopeMap to validate every dp:* scope in
roles.yaml against the Developer Portal’s declared scope set, rejecting unknown
or typoed names during startup/config validation while preserving existing
malformed-scope and ap:* validation.

---

Outside diff comments:
In `@portals/ai-workspace/production/README.md`:
- Around line 116-124: Update the production documentation tables at
portals/ai-workspace/production/README.md:116-124 to use
[platform_api.auth.authorization] and [platform_api.auth.claim_mappings]. Also
update the local override at portals/ai-workspace/README.md:377 to document
[platform_api.auth] mode = "idp".

---

Nitpick comments:
In `@platform-api/internal/middleware/role_scope_map.go`:
- Around line 69-95: Update wellFormedScope to enforce the documented
namespace:name shape with an optional wildcard only as a trailing :* segment,
while allowing hyphens in foreign namespace or scope names such as
dp:api-key_read. Keep ValidateRoleScopeMap’s namespace-scoped behavior
unchanged: apply this syntax check to all scopes, then validate only
PlatformScopePrefix entries against the registry.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: eb270f1b-e719-400c-b60f-21523e3baf16

📥 Commits

Reviewing files that changed from the base of the PR and between ca6ae02 and eee2a1f.

📒 Files selected for processing (30)

• distribution/all-in-one/docker-compose.yaml
• kubernetes/helm/platform-api-helm-chart/templates/configmap.yaml
• kubernetes/helm/platform-api-helm-chart/values.yaml
• platform-api/README.md
• platform-api/config/config-template.toml
• platform-api/config/config.go
• platform-api/config/config.toml
• platform-api/config/config_multifile_test.go
• platform-api/config/config_test.go
• platform-api/config/default_config.go
• platform-api/internal/handler/auth_login.go
• platform-api/internal/handler/auth_login_test.go
• platform-api/internal/middleware/auth.go
• platform-api/internal/middleware/auth_role_extraction_test.go
• platform-api/internal/middleware/role_scope_map.go
• platform-api/internal/middleware/role_scope_map_test.go
• platform-api/internal/server/role_scope_map_test.go
• platform-api/internal/server/scope_route_coverage_test.go
• platform-api/internal/server/server.go
• platform-api/plugins/eventgateway/plugin.go
• platform-api/resources/roles.yaml
• portals/ai-workspace/Makefile
• portals/ai-workspace/README.md
• portals/ai-workspace/distribution/README.md
• portals/ai-workspace/docker-compose.yaml
• portals/ai-workspace/production/README.md
• portals/developer-portal/Makefile
• portals/developer-portal/distribution/README.md
• portals/developer-portal/docker-compose.platform-api.yaml
• portals/developer-portal/docker-compose.yaml