Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing user management from custom IdZ to CC #2505

Closed
klaus-sap opened this issue Sep 27, 2023 · 4 comments · Fixed by #2606, #2663 or #2850
Closed

Missing user management from custom IdZ to CC #2505

klaus-sap opened this issue Sep 27, 2023 · 4 comments · Fixed by #2606, #2663 or #2850
Assignees

Comments

@klaus-sap
Copy link
Contributor

User Management in CF UAA from Multiple Identity Zones

Context

This issue proposes enhancing UAA to support user management from multiple identity zones. Customers will be able to manage their user accounts from own identity zones. These user accounts will be copied to the default identity zone for access at runtime.

Proposal

To address the operational and security requirements outlined above, this issue proposes enhancing CF UAA to support user management from multiple identity zones. This requires changes to UAA as outlined below.

  1. Currently, all CF user accounts are stored in the default identity zone “uaa” only, because cloud controller cannot deal with multiple identity zones. As a consequence, in multi-customer installations we cannot give user management credentials to single customers, as they would be able view or modify user accounts from other customers. On the other hand, web-based applications like service dashboards or other client applications run token flows against the default identity zone of UAA. At runtime, user accounts, OAuth clients and identity providers are expected to be available from the default identity zone of UAA.
  2. Customers should be able to do user management in their own identity zones. User accounts should be copied from customers identity zones to the default identity zone to be available at runtime.
  3. In addition, it must not be possible for customers to break out from their identity zones. 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.
  4. Landscape administrators with access to the default identity zone “uaa” may list all users with one single API call to the /users endpoint of the default zone.
  5. Components like Cloud Controller or Command Line Interface will continue logging on to the default identity zone of UAA. Cloud Controller administrators will continue to assign user accounts from the default identity zone “uaa” to CF roles like “Organization Manager”.
  6. Each user account is linked to an identity provider by the origin attribute. Customers may administrate user accounts from own identity providers only.

image

To implement the requirements mentioned above, we propose to enhance UAA user accounts with optional attributes “alias_id” and “alias_zid”. If these attributes are set, user accounts will be copied from the custom identity zone to the default zone (or vice versa in case of migration of existing users). We propose copying users instead of creating references, because we want to create separate user records in default and custom identity zone. With separate user records, we can continue to use simple SQL queries for all database operations.
Certainly, user administrators must not be able to freely choose alias_ids. Instead, the alias_id is set to the user id of the corresponding alias user.

In the same way, identity providers may be copied from the custom identity zone to the default identity zone (or vice versa). The origin attribute of each user account must be present as identity provider in the same identity zone.

Zone independent administrative scopes like “uaa.admin” or “cloud_controller.admin” must not be assigned to any user from custom identity zones. However, we may assign zone specific scopes like “zones.(zid).scim.write” to user administrators in custom identity zones. To prevent the assignment of zone independent admin scopes to users from custom identity zones, we propose to enhance identity zone definitions with optional blocklists of groups. The groups from a blocklist must not be created in the corresponding identity zone.

@cf-gitbot
Copy link

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/186133317

The labels on this github issue will be updated when the story is started.

philippthun added a commit to sap-contributions/cloud_controller_ng that referenced this issue Oct 11, 2023
While working on the "Support UAA identity zones in CC" PoC [1], I did
some refactoring that I would like to keep although the PoC is not going
to get implemented (see [2]).

[1] cloudfoundry#3341
[2] cloudfoundry/uaa#2505
rroberts2222 pushed a commit to loggregator/cloud_controller_ng that referenced this issue Dec 19, 2023
While working on the "Support UAA identity zones in CC" PoC [1], I did
some refactoring that I would like to keep although the PoC is not going
to get implemented (see [2]).

[1] cloudfoundry#3341
[2] cloudfoundry/uaa#2505

Co-authored-by: Andrew Crump <crumpan@vmware.com>
@strehle strehle linked a pull request Dec 20, 2023 that will close this issue
@strehle strehle reopened this Dec 20, 2023
@cf-gitbot
Copy link

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/186718998

The labels on this github issue will be updated when the story is started.

@Tallicia
Copy link
Contributor

Tallicia commented Apr 10, 2024

@klaus-sap @strehle @adrianhoelzl-sap Are there further PRs expected for this issue?

@adrianhoelzl-sap
Copy link
Contributor

@klaus-sap @strehle @adrianhoelzl-sap Are there further PRs expected for this issue?

Yes, there will be at least two more:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment