dimas-b commented on code in PR #1353:
URL: https://github.com/apache/polaris/pull/1353#discussion_r2047914839
##########
service/common/src/main/java/org/apache/polaris/service/admin/PolarisAdminService.java:
##########
@@ -771,6 +771,9 @@ public PrincipalWithCredentials
createPrincipal(PolarisEntity entity) {
PolarisAuthorizableOperation op =
PolarisAuthorizableOperation.CREATE_PRINCIPAL;
authorizeBasicRootOperationOrThrow(op);
+ if (PolarisEntity.isFederated(entity)) {
Review Comment:
The design doc does talk about this, but I do not recall firm decisions on
mentioned alternatives :)
Even if we create entities for federated principals, consider a use case
when someone creates a principal called `A` (non-federated) and later someone
else adds federation and federated principal with name `A` comes in (or the
other way around). Where is this conflict resolved? This is what I mean be
"manager".
Another use case: a federated principal `B` is created thought some IdP
integration logic and brings in some properties from the IdP. A user updates
principal `B` via Admin API. The doc mentions that being able to update
principal properties is desirable, but where do we resolve conflicts between
updated from the API and from the integration side?
--
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
