sneethiraj commented on issue #4291: URL: https://github.com/apache/polaris/issues/4291#issuecomment-4427487011
@dimas-b - Thanks for the clarification. That distinction makes sense. My intent here is not to assume that every PolarisPrincipal will always have a corresponding Polaris Principal Entity, or that entity-defined properties will be available in all authorization flows. The main use case I had in mind is for local Polaris users, where user-defined principal entity properties can be propagated into PolarisPrincipal and then made available to downstream authorization logic, such as Ranger policy evaluation. For example, deployments may want to define attributes such as department, region, tenant, project, or environment on a local Polaris principal and use those attributes in externalized policy decisions. I agree that for externally managed users, such as identities coming from Keycloak or another IdP, the PolarisPrincipal properties should generally come from the authenticator, for example from JWT claims or other request context. In those cases, there may not be any corresponding Polaris Principal Entity, and this change should not imply otherwise. So I see this as supporting one valid source of PolarisPrincipal properties for local Polaris principals, while preserving the broader design where pluggable authenticators remain responsible for populating principal properties based on the authentication mechanism being used. -- 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]
