[BUG] Incorrect usage of the X-Iceberg-Access-Delegation header

[dimas-b]

Is this a possible security vulnerability?

• This is NOT a possible security vulnerability

Describe the bug

Iceberg REST spec defines the following two values for the X-Iceberg-Access-Delegation HTTP header:

• vended-credentials
• remote-signing

However, current Polaris examples / docs use the value of true, which does not match anything in the Iceberg REST spec.

Current code appears to treat any non-empty header as vended-credentials, which is not exactly correct.

To Reproduce

No response

Actual Behavior

No response

Expected Behavior

• vended-credentials value is respected.
• remote-signing is clearly reported as an error (for now, cf. [FEATURE REQUEST] On-Premise S3 & Remote Signing #32).

Additional context

No response

System information

No response

[dennishuo]

This was definitely an unfortunate oversight; good catch!

Luckily, since the bug wasn't that the request handlers actually expected to parse true from the String, just that they only checked !isNullOrEmpty to assume it meant vended-credentials, it's forward-compatible if anyone is using the "correct" syntax.

We should try to update docs as quickly as possible to reduce the degree to which X-Iceberg-Access-Delegation: true gets entrenched into various workflows or test scripts of anyone integrating with Polaris.

At this point it may already be prudent to have an option for still falling back to the vended-credentials behavior if none of the comma-separated list of supported mechanisms is recognized (including the string "true").

[eric-maynard]

Hey @dimas-b , I think you fixed this in #211, right?

[eric-maynard]

This seems fixed so I'm closing it out for now -- please re-open if need be.

[dimas-b]

Yes, #211 fixes this... not sure how I forgot to cross-reference 🤦