/v3/roles does not validate the existence of user guid

[vchrisb]

It is possible to create a space/org role for an arbitrary user guid. The following does succeed, event if the guid does not exist:

cf curl /v3/roles -X POST   -d '{
     "relationships": {
       "organization": {
         "data": {
           "guid": "5989b03b-4d88-4eb7-a4a7-5bc428cd31bc"
         }
       },
       "user": {
         "data": {
           "guid": "not-existing"
         }
       }
     },
     "type": "organization_manager"
   }'

For a user, the cc api is validating if it exists, and will fail:

{
 "relationships": {
   "organization": {
     "data": {
       "guid": "5989b03b-4d88-4eb7-a4a7-5bc428cd31bc"
     }
   },
   "user": {
     "data": {
       "username": "not-existing"
     }
   }
 },
 "type": "organization_manager"
}

From briefly looking at the code https://github.com/cloudfoundry/cloud_controller_ng/blob/main/app/controllers/v3/roles_controller.rb#L123 , no lookup is done if a GUID is passed as part of the message.

I stumbled across this, as the cf cli is currently testing if a client exist, by calling uaa api, when using set-org-role or set-space-role. But to be able to test for existence, the authenticated user needs to have the clients.read scope, which isn't normally available. https://github.com/cloudfoundry/cli/commit/5b0cf09cb4350e5385e756d93580568516c47e1e I think the check should be moved to the cc api and not handled in the cf cli. This would improve the usability of clients with the cf cli.

[vchrisb]

Hey @svkrieger, are you looking into this? 🥇

[gogolok]

We also stumbled over that one.

I'm not sure what the intended behaviour of this endpoint is regarding user creation with user guid:

https://v3-apidocs.cloudfoundry.org/version/3.196.0/index.html#create-a-role If the associated user is valid but does not exist in Cloud Controller’s database, a user resource will be created automatically.

What is a valid user for example?

[johha]

A valid user is a user which exists in UAA/IDP.

I think the reason why there is no user existence check in the CF API is to reduce the load within the CF API as this would introduce an additional request to UAA. This load issue was one of the things we discussed when implementing the shadow user creation (cc.allow_user_creation_by_org_manager - RFC-0033). From a security point of view this is not an issue because a non existing user cannot login.