[RFC] User Account Management in Cloud Foundry with Multiple Identity Zones #665
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,51 @@ | ||
| # Meta | ||
| [meta]: #meta | ||
| - Name: User Account Management in Cloud Foundry with Multiple Identity Zones | ||
| - Start Date: 2023-08-04 | ||
| - Authors: @FloThinksPi, @klaus-sap, @philippthun | ||
| - Status: Draft | ||
| - RFC Pull Request: https://github.com/cloudfoundry/community/pull/665 | ||
|
|
||
| ## Summary | ||
|
|
||
| This RFC proposes enhancing Cloud Foundry (CF) to support users from multiple identity zones within the CF User Account and Authentication (UAA) system. The objectives are to enable efficient user management, facilitate data isolation and allow customized security measures. | ||
|
|
||
| ## Problem | ||
|
|
||
| CF operators are currently limited to the default identity zone within the UAA system for user account management. However, the need to store user accounts in different zones may arise from two distinct operational requirements: | ||
| 1. CF installations servicing multiple customers or tenants (e.g. public PAAS) must ensure absolute isolation of user accounts. Each customer or tenant must have their user accounts securely stored in separate identity zones to prevent unauthorized access to sensitive data. It is crucial that users from one customer cannot view, modify, or access the user accounts of other customers. | ||
| 1. Even in cases where CF is deployed for a single customer or organization, there may be a need to employ multiple identity zones. This could arise when customers wish to segregate user accounts based on roles, affiliations, or subsidiaries. By creating distinct zones, organizations can enforce specific security measures tailored to different user groups, such as implementing Multi-Factor Authentication (MFA) for certain privileged users. | ||
|
|
||
| ## Proposal | ||
|
|
||
| To address the operational and security requirements outlined above, this RFC proposes enhancing CF to support users from multiple identity zones within the CF UAA system. This requires changes to various components as outlined in this section. | ||
|
|
||
| ### User Account and Authentication | ||
|
|
||
| 1. Currently, web-based applications like service dashboards or other client applications like "cf ssh" run the authorization code flow against the default identity zone of UAA, which is advertised by the foundation’s api root (`/`) and info endpoints. This flow shall be extended to work with user accounts from other identity zones, too. | ||
| 1. The login page of UAA shall allow switching from the default identity zone (empty subdomain) to another identity zone/subdomain. UAA may store the favorite zone/subdomain in a cookie. | ||
| 1. The `/oauth/authorize` endpoint in the default identity zone shall be able to access security sessions from other identity zones and return authorization codes belonging to other identity zones. | ||
| 1. The `/oauth/token` endpoint in the default identity zone shall accept authorization codes belonging to other identity zones and return access tokens from the right zone, i.e. tokens with claim `zid` set to the zone ID of the user who has logged in. | ||
| 1. The `/check_token` endpoint in the default identity zone should be able to verify tokens from all identity zones, i.e. the claim `zid` must be considered to choose the right identity zone for token verification. | ||
| 1. With these changes it should be sufficient to create clients with the authorized grant type `authorization_code` in the default zone only. Along with these clients, the OAuth issuer and verification keys of all zones should be taken from the default zone. | ||
| 1. In addition, it must not be possible for customers to break out from their identity zone. Customers must not be able to assign authorizations to users, which grant access to other identity zones. In the same way it must not be possible to assign administration authorizations like `cloud_controller.admin` to users from a non-default identity zone. Only predefined scopes should be assignable by user administrators in non-default zones. | ||
| 1. With authorization `uaa.admin` or wildcard scopes across all zones (e.g. `zones.*.scim.read`) it should be possible to list all users from all zones with one single API call. | ||
|
|
||
| ### Cloud Controller | ||
|
|
||
| 1. The Cloud Controller (CC) shall authenticate users with tokens from non-default identity zones. The OAuth issuer and verification keys shall be taken from the default zone. | ||
| 1. User lookups must be performed within the identity zone of the authenticated user. SCIM queries shall be done with the `X-Identity-Zone-Id` header set to the `zid` of the user token. When a user interacts with the CC and requests information about other users who are part of their organization, the following behavior shall be implemented: | ||
| 1. For users who reside in the same zone as the authenticated user, the CC shall display their usernames. | ||
| 1. For users who belong to a different zone from the authenticated user, the CC must not display their usernames, but only the user GUIDs. | ||
|
There was a problem hiding this comment. What is a case where a user would be able to see a user from a different zone? If these identity zones are segmented by organization, then I don't think a non-admin user would encounter a user from another zone. Asking because I'd prefer to avoid adding this complexity to CC, if we can avoid it. |
||
| 1. Users with a CC admin scope (e.g. `cloud_controller.admin`) can lookup users across all identity zones, i.e. the CC shall display the usernames for all users. | ||
|
|
||
| ### Command Line Interface | ||
|
|
||
| 1. The commands "cf login" and "cf auth" must be enhanced by introducing an optional parameter to specify the desired identity zone for authentication. The new parameter should allow users to provide the subdomain of the target zone, not the zone ID. If not provided, the default identity zone will be used for login/authentication. | ||
|
|
||
| ## Backward Compatibility and Migration Considerations | ||
|
|
||
| Given the nature of this feature enhancement, it is designed to be an opt-in, thus preserving backward compatibility by default. This means existing configurations will not be impacted unless operators actively choose to enable multiple identity zones. | ||
|
|
||
| However, once multiple identity zones are activated, it's inevitable that some user accounts will require migration to suitable zones based on the organization's specific operational needs. The process of such migration, including its specific operational steps, is beyond the scope of this document. | ||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One additional problem that this RFC tries to solve: Customers want to have full control of their CF users, i.e. create users, assign CF roles, and finally also remove users. It should be possible for customers to implement a central user provisioning based on their needs.
This is not possible with a central UAA using the default identity zone only because we can't grant admin access for the default zone to customers. Admin access for a customer identity zone would solve this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. The use case is also about having multiple organizations sharing the same CF foundation, where each of the orgs needs to self-manage their CF users. That is indeed not easy today.
But here's what might work today
Deploy one UAA for each organization, then add each of these org-specific UAA as an external identity provider of the main system UAA. This way, people can log into the main system UAA with their org-specific UAA, and then proceed to access CF.
Pro: Secure isolation of user pools (physical isolation, as different UAAs are using different DBs and running on different VMs; in contrast, identity zones is only a simple logical isolation, which is quite flawed and prone to vulnerabilities). Little/no changes required in various CF components (this is how federated cf logins work today).
Cons: Operational costs of running additional UAA instances.
additional option
You might even be able to just add one non-system identity zone as an external identity provider of the main system UAA zone (on the UAA instance). But I haven't verified that it works (but I don't see why not).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterhaochen47: Thanks for your comments.
Let's see what @klaus-sap, @tack-sap, @strehle and colleagues think about the approach with additional UAA (zones) as external identity provider.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterhaochen47 The operational costs itself are imho a showstopper for org-specific UAA instances. Apart from that, the UAA integration with central landscape components (which need access to all UAAs) becomes overly complex and would most probably not scale.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@torsten-sap how about this option:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes but the resulted user token is then with zid:uaa means that users are within the system (uaa) zone, but we need and what separate users (and other related entities like idps or groups) into an own zones, so that a zone can be configured independently from another zone. That is what we support today in UAA, but not in cloud controller...
The move of groups and IdPs into the customer zone is not a big challenge, but the oauth clients (e.g. existing dashboards https://docs.cloudfoundry.org/services/dashboard-sso.html ) and their configuration with secrets is something I think about improvements, so that not all dashboard clients need to be copied into each single zone, therefore we want extend the central check_token endpoint. The details we should discuss in our call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though "the resulted user token is then with zid:uaa" when you log into the system (uaa) zone by logging into a custom zone, the user is still located in the custom zone (a.k.a. you cannot independently log into the system zone with that user). And you can still configure this custom zone separately. It's similar to that when you log into uaa system zone via Azure AD and get a UAA token, the user is still located in Azure AD.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true, but then we have the same as today. What we want have is a separation of users so that different administrators can manage these different users. Then we would need a new administrator, the origin admin who only can manage users and groups for a certain origin.