singhpk234 commented on code in PR #3228:
URL: https://github.com/apache/polaris/pull/3228#discussion_r2601317782
##########
extensions/auth/opa/impl/src/main/java/org/apache/polaris/extension/auth/opa/OpaPolarisAuthorizer.java:
##########
@@ -95,6 +95,21 @@ public OpaPolarisAuthorizer(
this.objectMapper = objectMapper;
}
+ @Override
+ public boolean requiresPrincipalRoles() {
+ return false;
+ }
+
+ @Override
+ public boolean requiresCatalogRoles() {
+ return false;
+ }
+
+ @Override
+ public boolean requiresResolvedEntities() {
+ return false;
+ }
Review Comment:
> I'm not sure what you mean by "delegated" AuthZ 🤔 The PolarisAuthorizer
interface has multiple implementations, but I do not think this is "delegation"
per se... Maybe I'm missing some context
I see, my understanding the reason why we don't use the principalRoles /
catalogRoles etc as the grants etc are managed by external system which is OPA
here which gives us an AuthZ decision (YES | NO) hence the Authorization is
delegated here as otherwise PolarisAuthZ would have required these stuff as
grants etc are done based on that. This is what i had in mind, in context of
above so here is what my thought process was considering the code change :
```java
public interface SupportsDelegatedAuthZ {
default boolean requiresPrincipalRoles() {
return false;
}
default boolean requiresCatalogRoles() {
return false;
}
default boolean requiresResolvedEntities() {
return false;
}
}
```
```
OPAAuthZ implements PolarisAuthZ, SupportsDelegateAuthZ {
// overrides
}
```
THis way persistence who wanna optimize to not look up prinicipal role and
catalog role can first check SupportsDelegateAuthZ and skip the look ups
accordingly.
Again i am thinking out loud here !
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
