HDDS-15984. [STS] Improve s3:prefix Condition handling and reject unsupported AssumeRole parameters

[fmorg-git]

Please describe your PR in detail:

• Currently, the following invalid session policy is being silently ignored instead of rejected, so this ticket will improve the handling:

{
    "Version":"2012-10-17",
    "Statement":[
      {
        "Effect":"Allow",
        "Action":"s3:ListBucket",
        "Resource":"arn:aws:s3:::my-bucket",
        "Condition":{
          "StringEquals":{
            "s3:prefix":"logs/*",
            "aws:username":"admin"
          }
        }
      }
    ]
  }

Separately, currently unsupported AssumeRole api parameters are being ignored rather than being rejected. This ticket will improve that as well.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-15984

How was this patch tested?

unit tests and smoke tests

[Copilot]

Pull request overview

This PR tightens validation in the S3 STS (AssumeRole) surface by rejecting previously-ignored unsupported parameters, and improves IAM session policy parsing to reject invalid s3:prefix condition shapes instead of silently accepting/ignoring them.

Changes:

• Add explicit validation for AssumeRole parameter names (GET query params and POST form params), distinguishing “AWS-valid but not implemented” vs “unsupported”.
• Update the STS POST endpoint to consume a form payload as a single entity and validate only body parameters (ignoring query string params for POST).
• Reject IAM session policies that specify multiple Condition keys per operator (e.g., StringEquals containing both s3:prefix and another key).

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
hadoop-ozone/s3gateway/src/test/java/org/apache/hadoop/ozone/s3sts/TestS3STSEndpoint.java	Adds unit tests covering new AssumeRole parameter validation behavior for GET and POST.
hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3sts/S3STSEndpointBase.java	Adds a safe helper to access query parameters from the request context.
hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3sts/S3STSEndpoint.java	Implements AssumeRole parameter validation (allowed vs unsupported vs not-implemented AWS params) and updates POST handling to consume Form.
hadoop-ozone/common/src/test/java/org/apache/hadoop/ozone/security/acl/iam/TestIamSessionPolicyResolver.java	Adds test cases ensuring multiple Condition keys (including ordering variations) are rejected.
hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/security/acl/iam/IamSessionPolicyResolver.java	Enforces “exactly one Condition key per operator” in s3:prefix condition parsing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ChenSammi]

+1

[fmorg-git]

updated

[ChenSammi]

If form is null, can we just response with error directly?

[fmorg-git]

updated

[ChenSammi]

It looks like AWS STS support ”application/x-www-form-urlencoded“ and “application/x-amz-json-1.1”, we only support the first one?

[fmorg-git]

per my investigation, AWS STS and IAM strictly use the AWS Query Protocol (which has application/x-www-form-urlencoded as the content type). Only newer services like Amazon Cognito, Amazon DynamoDB, Amazon SQS, etc support AWS JSON RPC 1.1. (not sure if you saw SQS and thought it was STS).