Error updating a oauth client

Hi,

I'm trying to update an oauth client from terraform provider. When I execute the terraform plan, it's detected a change, and when start to apply is received a message error "Error: 400 - The user does not have access to some of the specified roles. Users may only assign roles that they have to the client."

My user has the roles applied properly and the client credentials used by terraform provider is created by me. I used the same request from API Explorer (updating the syntax) with my user and it was worked. I don't understand what is the permissions problem.

API Explorer request:
{
"name": "Test",
"accessTokenValiditySeconds": 86400,
"authorizedGrantType": "CLIENT-CREDENTIALS",
"state": "active",
"roleDivisions": [
{
"roleId": "----------------id1-----------------",
"divisionId": ""
},
{
"roleId": "----------------id2-----------------",
"divisionId": "
"
},
{
"roleId": "----------------id3-----------------",
"divisionId": "*"
}
]
}

Terraform resource:
resource "genesyscloud_oauth_client" "Test" {
access_token_validity_seconds = 86400
state = "active"
authorized_grant_type = "CLIENT-CREDENTIALS"
name = "Test"
roles {
role_id = "----------------id1-----------------"
division_id = ""
}
roles {
role_id = "----------------id2-----------------"
division_id = "
"
}
roles {
role_id = "----------------id3-----------------"
division_id = "*"
}
}

Please, could you give me an idea ?

Thanks

You're talking about two separate things here, and the error message is only making the situation less clear. Your user, the one you use to make API requests using API Explorer, is entirely unrelated to the client credentials used by terraform. Your user works because you have different permissions/divisions assigned to your user than are assigned to the client credentials OAuth client.

The error from terraform uses the word "user" but it doesn't technically mean that. What it actually means is "the subject of the authorization used to make this request". In the case of running terraform with client credentials, it's referring to the client credentials OAuth client. That OAuth client must have all the roles assigned to it that you're trying to assign to the new OAuth client in terraform.

This caveat exists because if a request is able to grant an OAuth client permissions that the requester does not have, that would be a vector of attack in the system. Check your OAuth client's role configs and make sure it has everything that you're attempting to assign via terraform.

I ran into this issue today, too. I am creating a Terraform module which will create several resources, including:

  • A Role
  • A Group (which references the Role)
  • An Integration to embed a website (which references the Group)
  • An OAuth Client with the Client Credentials grant type (which also references the Role)

Following best practices, I want to execute this Terraform module using the Terraform CLI while authenticating the Genesys Cloud provider using an OAuth Client in our Organization which has enough permission to create these resources. I'll call this client the "CX Client".

My challenge is that the CX Client can't both create the Role and assign it to the New Client. I know this is because Genesys prevents a User (either human or OAuth) from assigning Roles which it does not also have.

However, this limitation creates a bit of a "chicken or the egg" problem. I want this Terraform module to create all my resources such that all resources are ready to use once done. But the New Client won't have all the required Roles, and the CX Client can't assign them. Additionally, the CX Client can't assign the new Role to my account either! I have to first assign the new Role to myself (since I have admin privileges) before I can assign it, too.

I designed this workaround:

  1. Create an "empty" Role (one with no Permissions at all).
  2. Assign the "empty" Role to the CX Client.
  3. Modify the Terraform module so that the New Client is assigned the empty Role.
  4. Use the CX Client to run the Terraform module.
  5. Manually assign the new Role to my own Person account using my admin privileges.
  6. Manually assign the new Role to the New Client.

Is there a better way to handle this situation?

Related, I saw a Permission called "General > Role Manager (Ability to assign roles to other users but not yourself)". I created a Role with this Permission and assigned this Role to the CX Client. However, even with that new Role, the CX Client couldn't assign a Role it didn't possess itself. Is this Permission only intended for human Users?

Thanks for the response. I know there is a lot here.

Hi Matthew,

There is no way to easily create a role and then assign it to the OAuth Client (other than how you have documented it). Genesys Cloud is very strict about roles and how they can be assigned to prevent an "escalation of privileges-style" attack. I have an inquiry for our Auth team about your role manager question.

Thanks,
John Carnell
Director, Developer Engagement

My scenario is similar to Mathew's scenario. I want to create several resources for a new client application.

By the moment, my workaround was to assign the role to the current oauth used to create the oauth client and create the new oauth client with this role with a python code. It does work!
Tim, I simulated the restrictions of Genesys UI when I create a new oauth client, and python code does work but terraform doesn't work.

I tried to repeat these steps with terraform with two approach:

  1. All resources in same execution of terraform but generating dependencies between resources
  2. Separated executions to create roles, assign role to user and then create a new oaith client.

I suppose there is another additional restrictions like explained John.

Hi @John_Carnell,

Did you get a response from the Auth team regarding the Role Manager? That would be an extremely helpful solution.

Thanks,
Matthew

Hi @John_Carnell,

I'm sure you're very busy with other initiatives. I appreciate you helping out with this discussion earlier.

I wanted you to know we are still interested in simplifying our workaround and hoping that the Role Manager Permission would be a solution. I fully understand and echo your concern about an "escalation of privileges" style attack. Still, there are many legitimate use cases for a Role Manager, and I hope we can learn more about that soon.

Thanks,
Matthew Pfluger

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.