[harshalbrahmbhatt-cohere]

Closes #1183.

Following the discussion in #1183, this implements the STS-style approach rather than R2-style. It is limited to GetFederationToken, the one STS action that issues credentials narrowed by a session policy without needing an IAM role store. A configured identity mints short-lived credentials limited to some buckets, key prefixes and operations, and stock AWS clients use them unchanged.

aws --endpoint-url http://127.0.0.1:8080 sts get-federation-token \
    --name alice-job --duration-seconds 3600 \
    --policy '{"Statement": [
      {"Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"],
       "Resource": "arn:aws:s3:::data/users/alice/*"},
      {"Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::data",
       "Condition": {"StringLike": {"s3:prefix": "users/alice/*"}}}]}'

Design. It is fully stateless. The session token is AES-256-GCM over the temporary key ID, expiry, name and policy, under a key derived with HKDF from the minting identity's secret. The temporary secret is an HMAC of the key ID under a second derived key. Any replica with the same identity verifies tokens, and rotating the identity's secret revokes every session it minted. It is opt-in through s3proxy.sts.enabled, and requires aws-v4 or aws-v2-or-v4 authorization.

Policy subset.

• Supported: Allow and Deny (explicit Deny wins), Action and Resource with wildcards, and StringEquals/StringLike on s3:prefix and s3:delimiter.
• Refused with MalformedPolicyDocument rather than ignored: everything else.
• Each operation is checked against the IAM action AWS documents for it. That includes the copy source, every DeleteObjects key, and PutObjectAcl for a non-private x-amz-acl.

Demonstrated with existing tools. You mentioned session_policy in s3-tests. Those tests all go through AssumeRoleWithWebIdentity, which needs an IAM role API, OIDC providers and Keycloak, so they are out of scope here. Instead:

• StsFederationTokenTest: AWS SDK v2 StsClient and S3Client against a live proxy. It covers allowed and denied matrices, copy, multipart, DeleteObjects, presigned URLs, tampered, expired or mismatched tokens, parent-secret rotation, and body-tamper on STS requests.
• src/test/resources/run-sts-cli-tests.sh: the stock AWS CLI end to end against the packaged jar. It is not yet wired into CI; happy to add it if you'd like.
• s3-tests results are unchanged with STS enabled.

Separate commit, also relevant without STS. On stub backends (filesystem, transient, sftp), a multipart upload ID was not bound to its key. A request naming one key could complete or abort another key's upload and inherit its ACL and metadata. The stub is now named by upload ID plus a key digest, and wrong pairs get NoSuchUpload as in S3. Stubs written before the upgrade are still honoured.

Limitations (also in docs/STS.md):

• Only GetFederationToken; no AssumeRole, GetSessionToken or GetCallerIdentity.
• No POST-policy uploads and no SigV2 with session credentials.
• Parent secrets must be strong, since temporary credentials allow offline guessing.
• On a case-insensitive filesystem, the filesystem backend doesn't separate keys that differ only in case.
• Under s3proxy.service-path, SDKs can't mint, because the path without a trailing slash redirects.

[gaul]

Thanks, this is a careful piece of work. I read the STS side closely and found nothing to fix:

• Token: HKDF with the parent in the salt, AES-GCM with the header as associated data, and the token's access key bound to the signature.
• Requests: checks are deny-by-default, with authorize on every operation; copy sources and DeleteObjects keys are checked too, and non-canonical keys are refused.
• Policy: unsupported syntax fails closed.
• STS endpoint: no-policy sessions get deny-all, sessions can't mint more, and signatures are scoped to their service.

CI is red because of the multipart commit. MultipartUploadKeyBindingTest runs on every lane, but the binding exists only on the stub backends:

• On Azure, GCS and Swift, Complete Multipart Upload with another key's upload ID isn't refused (line 94).
• On LocalStack and MiniStack, Abort isn't (line 97).

I reproduced the native-backend case on master against Azurite and filed it as #1235. I created an upload for a and uploaded a part, then sent Complete naming b. The response was 200 with Key: b, but it finished the upload for a, and b was never created.

That matters for this PR. A session's policy is checked against the key the request names, while the store completes the upload the ID belongs to. So a session limited to users/alice/* can complete an upload in progress under users/bob/*, given its upload ID, which ListMultipartUploads reveals. I think the binding needs to hold on every backend before STS can rely on key-scoped policies. Could you move the multipart commit into its own PR and either:

• check the pairing for every backend, for example in the handler before Complete, Abort, UploadPart and ListParts; or
• if that is too broad for now, gate the test to the stub backends and refuse CompleteMultipartUpload and AbortMultipartUpload for sessions on the other backends until they bind?

Two smaller things:

• run-sts-cli-tests.sh isn't run anywhere. Either wire it into the filesystem lane or drop it, since a script nothing runs goes stale.
• s3-tests results are fine to leave as you stated them.