collado-mike opened a new issue, #441: URL: https://github.com/apache/polaris/issues/441
### Is your feature request related to a problem? Please describe. User management is complicated and can scale to thousands or tens of thousands of users for large enterprises. Group membership is frequently dynamic and privileges tied to group membership needs to be able to reflect group membership changes immediately. Large enterprises typically use identity provider services, such as Okta, LDAP, or Google, to manage users and roles. These central IdPs are typically relied upon to communicate user authentication and group membership so that an administrator needs to make changes in a single central location and know that all peripheral applications will see those changes immediately. ### Describe the solution you'd like SSO and support for Federated Users and Federated Roles would allow defining users and roles as "federated" so that token generation and role membership is disallowed through the Polaris management APIs. I see the following changes being implemented: 1. Support for multiple `Authenticator`s to be configured - an admin could potentially have multiple IdPs that should be trusted to generate auth tokens. These tokens need to be inspected and validated in Polaris, potentially by making an API call to the IdP or by validating an encryption signature in a JWT. 2. Extending the authentication flow to support just-in-time Principal creation - when a `TokenBroker` parses a token and returns a user that doesn't have a principal entity, one should be created from the token info. The Principal should be marked as `federated` in its `internal_properties`. A `federated` Principal does not have any clientId/secret stored and cannot generate a token in the `/tokens` API. 3. Extending the authentication flow to support just-in-time PrincipalRole creation and assignment - when a `TokenBroker parses a token, the scopes defined in the token should translate into PrincipalRole membership. These roles may not exist in Polaris, so should be created. The `AuthenticatedPrincipal` will implicitly have membership in these `PrincipalRole`s. The `PrincipalRole` should be marked as `federated` in its `internal_properties`. A `federated` PrincipalRole cannot be granted to non-`federated` Principals. 4. `federated` Principals also cannot be granted membership to a non-`federated` PrincipalRoles - the tokens generated by the IdP will never include a non-`federated` PrincipalRole, so granting membership doesn't make sense. 5. Both `federated` Principals and PrincipalRoles must have a `federation_source` - a `federated` Principal should only be granted access to PrincipalRoles that are defined for the same `federation_source`. A naming convention, such as a source prefix, should be considered to avoid name clashing of Principals and PrincipalRoles. It would be necessary to map scopes and usernames present in the token to the expected name of the created Principal/PrincipalRole. ### Describe alternatives you've considered _No response_ ### Additional context _No response_ -- 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]
