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:
Support for multiple Authenticators 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.
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.
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 PrincipalRoles. The PrincipalRole should be marked as federated in its internal_properties. A federated PrincipalRole cannot be granted to non-federated Principals.
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.
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.
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:
Authenticators 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.TokenBrokerparses 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 asfederatedin itsinternal_properties. AfederatedPrincipal does not have any clientId/secret stored and cannot generate a token in the/tokensAPI.TokenBrokerparses a token, the scopes defined in the token should translate into PrincipalRole membership. These roles may not exist in Polaris, so should be created. TheAuthenticatedPrincipalwill implicitly have membership in thesePrincipalRoles. ThePrincipalRoleshould be marked asfederatedin itsinternal_properties. AfederatedPrincipalRole cannot be granted to non-federatedPrincipals.federatedPrincipals also cannot be granted membership to a non-federatedPrincipalRoles - the tokens generated by the IdP will never include a non-federatedPrincipalRole, so granting membership doesn't make sense.federatedPrincipals and PrincipalRoles must have afederation_source- afederatedPrincipal should only be granted access to PrincipalRoles that are defined for the samefederation_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