dimas-b commented on PR #3427: URL: https://github.com/apache/polaris/pull/3427#issuecomment-3762293191
> how do you envision the relationship of persistence impl <-> resolver impl <-> auth impl to be in an ideal world? Rough sketch :) * REST API provides initial "seeds" (generally catalog paths or names) for the Resolver * Resolver "outputs" are Entities found from those "seeds". * The resolution algorithm is specific to the Persistence impl. (this is where Resolver sub-classes may be needed as I commented above). The one for JDBC uses current parent ID bases loop. The one for NoSQL uses direct lookup by path/name (this one may be implemented later). * One of the "seeds" is the Principal + Role Names (provided by existing AuthN code) * Whether Principal + Roles needs to be resolved to Entities is indicated by the Authorizer impl. This part is common to all Resolvers and can probably be done in the common base class. * Ideally there is only one resolution "action" - it produces the complete data set for the service endpoint to perform AuthZ and actual API impl. logic. Some early abandoned ideas can be found in #499, but we do not have to do it exactly that way. WDYT? -- 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]
