[RFC] User Account Management in Cloud Foundry with Multiple Identity Zones

[philippthun]

Link for easier viewing: https://github.com/philippthun/community/blob/rfc-multiple-identity-zones/toc/rfc/rfc-draft-multiple-identity-zones.md

[philippthun]

@cloudfoundry/toc - FYI
@cloudfoundry/wg-foundational-infrastructure - Please provide feedback, especially to the UAA related changes.
@cloudfoundry/wg-app-runtime-interfaces - Please provide feedback, especially to the CAPI and CF CLI related changes.

Thanks,
@FloThinksPi, @klaus-sap, Philipp

[beyhan]

@philippthun Thank you for the proposed RFC. Could you please add a link for easier viewing like in the other RFCs, e.g. this one.

[peterhaochen47]

Hello, thanks for the proposal. Here are my comments:

About the problem statements

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.

I believe this problem has a solution currently. Imagine a public PAAS based on CF offered & operated by company Foo-Inc:

• Only the UAA admin users (users with UAA admin scopes; they should be employees from Foo-Inc, operating the PAAS) have the power to view/modify user accounts across all zones.
• Currently, a normal / non-admin user (aka a customer of the PAAS) cannot view, modify, or access the user accounts of other customers, regardless of zones.

Please provide specific concerns if you believe UAA currently does not guarantee this.

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.

This is true, currently the log-in config is applied uniformly to all users within an identity zone. However, could you provide more specific examples of these security measures that you want to apply differently to different sets of users? (UAA's native MFA feature is deprecated.) There could be existing solutions already. Or, there could be alternative solutions.

About the proposed changes

• The proposed changes weakens the isolation of identity zones.
  • Currently, a UAA instance's different identity zones can almost be treated as different instances of UAA (the exception is that the UAA admin users in the default system zone can access & manage all identity zones); the user data/access from different zones do not cross-pollinate. This was the design intention of the identity zone features (so that different tenants can safely share the same UAA without fear of leakage). If anything, one might argue that this isolation is not complete enough; after all, different zones still use the same database tables & are run by the same VM (hence, contains some risks of accidental cross-pollination). For the long term, it's probably more secure to deprecate identity zones all together (and people should deploy new UAA instances if they need another isolated user store).
  • The 4 proposed changes under "item 1" (cross-linking login domains, sharing security sessions, sharing authorization code, allow one zone to check tokens issued by another zones) seem to break down some of the barriers between zones & might result in more concerns for leakage.
    • These changes also seem like they would conflict with OAuth specs/principles (but I need to evaluate it more). For example, these changes would allow standard OAuth endpoints like /check_token and /oauth/token to accept token/code issued by other issuers (different identity zones are treated as different issuers).
• For item 3, "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." I believe this is true today.
• For item 4, "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." This is true today (except you have to make multiple API calls, each targeting one zone). Modifying UAA API to allow one request to access all zones's users seems risky in that it further breaks down the barriers between zones.

[stephanme]

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.

[peterhaochen47]

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).

[stephanme]

@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.

[torsten-sap]

@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.

[peterhaochen47]

@torsten-sap how about this 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).

[strehle]

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

[peterhaochen47]

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.

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.

[strehle]

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.

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.

[Gerg]

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.

[klaus-sap]

Thank you for the detailed feedback. It seems to me that the proposal from this RFC is a bit too complicated. Thus, we would like to propose a simpler approach, see cloudfoundry/uaa#2505

[philippthun]

Thanks for all the comments. I'm going to close (withdraw) this RFC.