feat(openai_responses): support aws_profile SigV4 auth for Bedrock OpenAI-wire#3463
Open
resrever wants to merge 6 commits into
Open
feat(openai_responses): support aws_profile SigV4 auth for Bedrock OpenAI-wire#3463resrever wants to merge 6 commits into
resrever wants to merge 6 commits into
Conversation
…enAI-wire The OpenAI Responses provider path previously stubbed out AuthDetails::AwsProfile (no auth header emitted), so AWS Bedrock's OpenAI-compatible endpoint (bedrock-mantle.<region>.api.aws/openai/v1/responses, which serves models like gpt-5.5 / gpt-5.4 over the OpenAI Responses wire but requires SigV4) returned 401 "Missing 'authorization' or 'x-api-key' header". This mirrors what PR tailcallhq#2831 did for BedrockProvider, but for the OpenAIResponses path: - Preserve the configured URL path when it ends in /responses (so /openai/v1/responses is not rewritten to /v1/responses). - Add sigv4_headers(): when the credential is AwsProfile, load profile creds via aws_config, SigV4-sign the request body (service "bedrock", region from the AWS_REGION url param), and inject Authorization / x-amz-date / x-amz-security-token. - Integrate into chat(); api_key / bearer / oauth behavior is unchanged. Adds aws-sigv4 1.4.4 (already in the lockfile via the AWS SDK). All existing tests pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
github-actions
Bot
added
the
type: feature
…ion test Makes the new OpenAI-Responses SigV4 path usable end-to-end: registers a built-in provider (response_type OpenAIResponses, URL templated on AWS_REGION and ending in /openai/v1/responses so the path-preservation branch triggers, auth_methods [aws_profile]). api_key is intentionally omitted because the OpenAI-Responses api_key path sends Authorization: Bearer, which is not valid SigV4 for this endpoint. Model context_length values are placeholders pending confirmation against the live Mantle endpoint. Adds a hermetic regression test asserting the Bedrock /openai/v1/responses path is preserved (not rewritten to /v1/responses). SigV4 header generation needs real AWS credentials, so it is not unit-tested here. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Live testing against the Bedrock OpenAI-wire endpoint shows the model ids must be prefixed with openai. (openai.gpt-5.5 / openai.gpt-5.4); the bare gpt-5.x ids were not accepted. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
GPT-5.5 / GPT-5.4 on the Bedrock OpenAI Responses (bedrock-mantle) endpoint expose a 1M-token context window per AWS and OpenAI docs; the 400k placeholder was the Codex-surface figure. Matches the repo other GPT-5.4 entries. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
Action required: PR inactive for 5 days. |
github-actions
Bot
added
the
state: inactive
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this enables
AWS Bedrock's OpenAI-compatible Responses endpoint (
bedrock-mantle.<region>.api.aws/openai/v1/responses, which serves models like GPT-5.5 / GPT-5.4 over the OpenAI Responses wire) requires SigV4 request signing and rejects API keys. Forge's OpenAI-Responses path previously stubbed outAuthDetails::AwsProfile(emitted no auth header), so these requests failed with:This PR SigV4-signs those requests using an AWS named profile and ships a built-in provider so it works out of the box. Because credentials resolve through the named profile and session tokens are forwarded (
x-amz-security-token), temporary credentials work too — profiles backed by AWS SSO / IAM Identity Center,assume-role, or acredential_processbroker.What changed
repository.rs): newsigv4_headers()— when the credential isAuthDetails::AwsProfile, load the profile viaaws_config(region from theAWS_REGIONurl-param, defaultus-east-1), SigV4-sign the request body for servicebedrock, and injectAuthorization/x-amz-date/x-amz-security-token. Wired intochat();api_key/bearer/oauthpaths are unchanged./responses, so/openai/v1/responsesisn't rewritten to/v1/responses.provider.json):bedrock_openai_responses—response_type: OpenAIResponses, URL templated on{{AWS_REGION}},auth_methods: ["aws_profile"], modelsopenai.gpt-5.5/openai.gpt-5.4. This surfaces it in:provider(with the "AWS Profile" auth option) andforge list provider.aws-sigv4 1.4.4(already in the lockfile via the AWS SDK).Mirrors what #2831 did for
BedrockProvider, applied to the OpenAI-Responses path.Notes
auth_methodsis intentionally["aws_profile"]only: this endpoint rejects plain keys, and the OpenAI-Responsesapi_keypath sendsAuthorization: Bearer, which isn't valid SigV4.BedrockProvider's SDK client) because the OpenAI-Responses path is plain HTTP viaHttpInfra, not the AWS SDK.Testing
/openai/v1/responsespath is preserved (not rewritten to/v1/responses).cargo test -p forge_repopasses.:provider→bedrock_openai_responseswith AWS profile auth →openai.gpt-5.5/openai.gpt-5.4are selectable and respond (SigV4 accepted, no 401).