cloudfoundry
Missing user management from custom IdZ to CC
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.
- 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.
- 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.
- 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.
- 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.
- 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”.
- Each user account is linked to an identity provider by the origin attribute. Customers may administrate user accounts from own identity providers only.
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.
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.
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.
@klaus-sap @strehle @adrianhoelzl-sap Are there further PRs expected for this issue?
@klaus-sap @strehle @adrianhoelzl-sap Are there further PRs expected for this issue?
Yes, there will be at least two more:
- https://github.com/cloudfoundry/uaa/pull/2769 alias handler for SCIM users
- https://github.com/cloudfoundry/uaa/pull/2663 integration of the alias handler into the SCIM user endpoints
