Deploy LLM providers without upstream authentication

[lahiruudayakumara]

Purpose

LLM providers configured without upstream authentication could not be deployed because the Platform API emitted an incomplete api-key authentication block without a credential. The gateway correctly rejected this configuration with spec.upstream.auth.value: Auth value is required when api-key auth type is set.

Resolves #2950.

Goals

• Allow LLM providers with authentication disabled to deploy successfully.
• Preserve the existing behavior for configured API-key authentication.
• Continue supporting the none and other authentication types.

Approach

During deployment artifact generation, an API-key authentication configuration with an empty credential is now serialized as:

auth:
  type: none

This prevents an invalid api-key block from reaching the gateway. API-key configurations containing a credential continue to be serialized unchanged.

A regression unit test verifies that empty API-key authentication is converted to none without emitting a header or value.

No UI changes are included.

User stories

• As an API developer, I can deploy an LLM provider whose upstream authentication is disabled.
• As an API developer, I can continue deploying LLM providers that use API-key authentication.
• As a gateway operator, I receive valid LLM provider deployment artifacts from the Platform API.

Documentation

N/A — this fixes deployment serialization to match the existing authentication behavior and does not introduce a new user-facing capability or configuration format.

Automation tests

• Unit tests

  • Added coverage for deploying an LLM provider whose API-key authentication has no credential.
  • Verified that the resulting authentication type is none.
  • Verified that no authentication header or value is emitted.
  • Existing tests for configured API-key, none, and other authentication continue to pass.
  • Full Platform API service test suite passed.
  • Gateway LLM upstream-auth validator test passed.
  • Code coverage percentage was not collected.

• Integration tests

  • Not added. The affected deployment serialization behavior is covered at the unit level, and the gateway validator behavior was independently verified.

Security checks

• Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes
• Ran FindSecurityBugs plugin and verified report? no — not applicable to this Go change
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes

Samples

N/A — no samples were added or modified.

Related PRs

N/A.

Test environment

• Operating system: macOS, ARM64
• Go toolchain: Go 1.26.5
• JDK: N/A
• Database: N/A
• Browser: N/A

[coderabbitai]

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 5a320912-1bdc-4b47-b213-c596eaaed875

📥 Commits

Reviewing files that changed from the base of the PR and between 3a205e7 and 4f723f9.

📒 Files selected for processing (2)

• platform-api/internal/service/llm.go
• platform-api/internal/service/llm_test.go

 __________________________________________________________________________________
< This is the beginning of a beautiful friendship...between you and bug-free code. >
 ----------------------------------------------------------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).

📝 Walkthrough

Walkthrough

Empty API-key authentication is now emitted as disabled authentication (none) without header or value fields, with a regression test covering the generated LLM provider deployment YAML.

Changes

LLM provider authentication

Layer / File(s)	Summary
Normalize empty API-key authentication platform-api/internal/service/llm_deployment.go, platform-api/internal/service/llm_deployment_test.go	mapModelAuthToAPI maps blank API-key credentials to none, and the regression test verifies that generated YAML omits header and value fields.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: malinthaprasan, renuka-fernando, anugayan

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: allowing LLM providers to deploy without upstream authentication.
Description check	✅ Passed	The description follows the template and includes purpose, goals, approach, user stories, tests, security, samples, related PRs, and environment.
Linked Issues check	✅ Passed	The code and test changes address #2950 by serializing empty API-key auth as none so disabled security can deploy successfully.
Out of Scope Changes check	✅ Passed	The changes are limited to the auth mapping fix and its regression test, with no obvious unrelated additions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.12.2)

level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain modules listed in go.work or their selected dependencies"

---

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.}

[Thushani-Jayasekera]

@lahiruudayakumara
I think we should introduce this behaviour during provider creation. If no API key value is provided when the provider is created, we should automatically set the upstream authentication type to None.

Thanks

[lahiruudayakumara]

Addressed. Provider creation now automatically sets the upstream authentication type to None when no API key value is provided. If a value is present, API key authentication is preserved. This applies to both main and sandbox upstreams.