aacampbell commented on PR #2244: URL: https://github.com/apache/polaris/pull/2244#issuecomment-3157180685
This new example is very helpful, and very clearly shows how things work. One thing to note: The `create_catalog.sh` script doesn't work except for the first realm, because it's hardcoded to hit the deprecated iceberg token endpoint. Switching the URL to Keycloak's, and dropping the scope argument, looks like it'll work. It does lead to an interesting train of thought. If we can expect that the deprecated iceberg `catalog/v1/oauth/tokens` endpoint will eventually be removed, what will be best practice? We will all have to use the `external` authentication type, which means complete dependence on an external system to use even the bootstrap admin user. I see there's another Issue #2238 regarding the bootstrapped admin having a hardcoded `root` principal name, which is what the principal-mapper must match. This would require a special-case external user in order to do any administration or even setup of other principals in Polaris. Being able to choose the bootstrapped admin's principal name would go some way to allowing uniform mapping of external IdP user attributes to principal names in Polaris, but this is getting to be more of an external concern. What isn't solved is the external dependence for doing _any_ administrative actions. Perhaps a small/basic token endpoint in the `management` api for getting administrative tokens? That might prevent Polaris from doing too much of the lifting for Auth while still allowing it to be securely administered without external dependencies. I think this would effectively be the same as the current "mixed" authentication case, except the endpoint is under the `management` api rather than the Iceberg `catalog` api. I feel like I got pretty far off topic here. Is there a more appropriate forum? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@polaris.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
