You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Fabian Morgan (Jira)" <ji...@apache.org> on 2026/02/20 07:42:00 UTC

[jira] [Updated] (HDDS-14681) [STS] Support StringLike Condition and handle certain errors more gracefully

     [ https://issues.apache.org/jira/browse/HDDS-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabian Morgan updated HDDS-14681:
---------------------------------
    Summary: [STS] Support StringLike Condition and handle certain errors more gracefully  (was: Support StringLike Condition and handle certain errors more gracefully)

> [STS] Support StringLike Condition and handle certain errors more gracefully
> ----------------------------------------------------------------------------
>
>                 Key: HDDS-14681
>                 URL: https://issues.apache.org/jira/browse/HDDS-14681
>             Project: Apache Ozone
>          Issue Type: Sub-task
>            Reporter: Fabian Morgan
>            Assignee: Fabian Morgan
>            Priority: Major
>
> When testing Polaris with the feature branch, it was discovered that Polaris is sending StringLike as a condition in the IAM session policy, which previously was being rejected as not supported per the design.  This ticket adds that support.  
> Furthermore, throughout the troubleshooting process, it was noticed that certain errors weren't being handled gracefully:
> 1) Unsupported Condition operator in IAM session policy was returning 500 Internal Server Error (instead of 501 Not Implemented)
> 2) Malformed JSON in IAM session policy was returning 500 Internal Server (instead of 400 Bad Request)
> 3) If the STS enabled flag was true, but the OzoneNativeAuthorizer was used instead of Ranger, this returned 500 Internal Server Error (instead of 501 Not Implemented)
> 4) When using STS Token for S3 API calls, if the assumed role in Ranger didn't have a requisite permission for the S3 API call, an AccessDenied (403) error was returned, which is fine.  However, the OM log had a warn message that the user associated with originalAccessKeyId did not have the permission, which was confusing when the user did actually have that permission and it was the assumed role that did not have the permission.
> These additional 4 issues are also addressed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org