Is STS Token Passthrough Supported in Polaris Federated Catalogs?

[RB-ETArch]

I am evaluating catalog federation behavior in a data lakehouse setup using Apache Iceberg with Apache Polaris.

Architecture:

• One central enterprise catalog
• Multiple BU level child catalogs federated into the central catalog

Expected flow (based on my understanding):

• Client queries an Iceberg table through the central catalog
• Central catalog forwards the request to the appropriate BU catalog after RBAC validation
• BU catalog returns table metadata and an STS token
• Central catalog returns the BU catalog’s metadata and the same STS token back to the client

Actual behavior observed:

• BU catalog does return metadata + STS token
• Central catalog drops/ignores the BU-provided STS token
• Central catalog generates a new STS token and sends that to the client instead

Question:
Is this the expected behavior for Polaris catalog federation (i.e., central catalog always re-issues STS tokens), or is this a bug / misconfiguration?

[dimas-b]

@dennishuo @XJDKC : WDYT?

[dimas-b]

@RB-ETArch : Regardless of the answer to your exact question, if your use case benefits from passing the vended credential through, it can certainly be implemented in Polaris with the help of feature flags.

Given that credential vending is a critical topic security-wise, I'd suggest opening a dev ML thread in that case (for better visibility and traceability).

[RB-ETArch]

Will do

[RB-ETArch]

created a dev thread

[dimas-b]

https://lists.apache.org/thread/b4t3y96nc80dcps1jyqwo913xwbokcmq

[flyrain]

Hi @RB-ETArch, what you described is the expected behavior. Passing through vended credentials across catalog federation is not considered safe.

One of the main reasons is that federation between catalogs is typically performed using a service principal. As a result, the vended credentials returned by the remote catalog could unintentionally carry administrative privileges.

To safely support credential passthrough, the original user or principal would first need to be propagated to the remote catalog so that both catalogs recognize the same identity. However, that alone is not sufficient. Even if both catalogs identify the same principal, they may not enforce the same permissions. For example, a user may have write permission in Catalog A but only read permission in Catalog B. In that case, blindly passing through the remote catalog's vended credentials could grant privileges that are inconsistent with the authorization decisions made by the central catalog.

[RB-ETArch]

@flyrain

In our setup users only talk to the central catalog and RBAC is enforced only in the central catalog. the central catalog talks to BU child catalogs using a service principal with read/write privileges.

Question: If a client requests a read operation, will the central (or BU) catalog mint a session policy that is read‑only on the table prefix (e.g., GetObject/ListBucket with a prefix condition) even though the federation service principal has admin rights, or does the inline policy reflect the service principal’s full privileges instead? My understanding is that the inline session policy in vended credentials is based on user operation (after RBAC validation).

[dimas-b]

@RB-ETArch : As I mentioned in my earlier post, I think the use case of vended credentials pass-through needs some thinking... which is why I believe a dev thread is preferable to a GH discussion (just more visible to the developer community).

Currently, IIRC, Polaris will assign credential policies based on what the user is allowed to do by the Authorizer, meaning that even read-only requests (such as loadTable) will return R/W credentials if the user is authorized to write.

[flyrain]

@dimas-b is right here. Moreover, for your settings, I believe it makes more sense to set the storage configuration at the central catalog for the federated catalogs. That way, you don't have to deal with fragile credentials passthrough.

[RB-ETArch]

Will respond to this in dev thread.
https://lists.apache.org/thread/b4t3y96nc80dcps1jyqwo913xwbokcmq