[RFC] User Creation by Org Managers

[stephanme]

Allow Org Managers to create users in UAA in order to improve the onboarding procedure for larger developer groups into multi-tenant Cloud Foundry foundations.

Preview

[stephanme]

FYI: @cloudfoundry/toc , @cloudfoundry/wg-app-runtime-interfaces-capi-approvers

[Gerg]

In this workflow, who or what is granting the user the Org Manager role? Could the Org Manager also be granted an appropriate scope to create users in UAA, instead of CC creating users on their behalf?

[Gerg]

cc @cloudfoundry/wg-foundational-infrastructure-identity-and-auth-uaa-approvers

[Gerg]

Overall, I'm a bit wary of adding a POST request to UAA nested inside of a synchronous CC request. We'd have to contend with issues of timeouts, error handling, audit-ability, etc.

Ideally, we could get the Org Manager users sufficient permissions to create the user in UAA themselves, maybe with the facilitation of the CLI?

[stephanme]

In this workflow, who or what is granting the user the Org Manager role? Could the Org Manager also be granted an appropriate scope to create users in UAA, instead of CC creating users on their behalf?

The initial Org Manager role is assigned by an external onboarding process that uses a technical CF admin user. From then on, the initial Org Manager can grant Org Manager role to additional users using CF CLI or any other CF API client (e.g. terraform).
Assigning a special UAA scope could work for the initial Org Manager (the external onboarding process could assign it) but not anymore for the additional ones - unless it is implemented in the POST /v3/roles endpoint which is even more complex compared to the proposed solution.

Overall, I'm a bit wary of adding a POST request to UAA nested inside of a synchronous CC request. We'd have to contend with issues of timeouts, error handling, audit-ability, etc.

That's a valid point. But on the other hand, POST /v3/roles calls already the UAA to get the user guid and as mitigation, the UAA POSTs are behind a config flag so that foundations that don't need this feature are not impacted.

[beyhan]

We discussed this during the TOC meeting on 01.10.2024 and decided to start the FCP with the goal to accept it during the next TOC meeting.

[Gerg]

I'm still nervous about nesting a synchronous POST request to UAA inside a CC request, but I understand the use case this RFC is trying to solve. I'm fine with this idea as long as it is off by default in cf-d.

I left a couple comments on details that I think should be addressed prior to acceptance.