Question: Guidance on okta_app_group_assignment and okta_app_user

[paullschock]

Hi All,

I hope this is an appropriate question in this forum.

My team publishes a module that allows teams to assign themselves to existing applications.

The code is fairly simple:

data "okta_user" "group_users" {
  count = length(var.user_emails)
  search {
    name  = "profile.email"
    value = var.user_emails[count.index]
  }
}

## Okta Resources ##
# Create Group
resource "okta_group" "custom_okta_group" {
  name        = local.okta_group_name
  description = "My custom for AWS federation"
  users       = data.okta_user.group_users.*.id
}

# Assign group to app
resource "okta_app_group_assignment" "custom_role_to_okta" {
  app_id   = var.okta_applic_id
  group_id = okta_group.custom_okta_group.id
}

This has worked for awhile, but we ran into an issue where okta_app_group_assignment would end up receiving a 5xx response from Okta API (when attempting to assign to one specific application) which ended up being the result of erroneous assignment of duplicate values for priority. Something that was resolved by running a script against the DB (or so I understood from the support agent).

In my initial troubleshooting of this I came across #483 and my observation is that the specific application that was triggering this issue has >1000 group assignments and is our "busiest" in terms of okta_app_group_assignment.

In light of the above issue and the related in-progress PR, is it advisable for us to reconsider our module?

Would something like (pardon my guess work pseudo code) be more advisable/scalable?

resource "okta_app_user" "custom_role_to_okta" {
  for_each = toset(data.okta_user.group_users[*].id)
  app_id   = var.okta_applic_id
  user_id = each.key
}

[faurel]

Hi @paullschock, I guess you are facing the same issue as we do : #738

[bogdanprodan-okta]

Hi, @paullschock! Thanks for submitting this issue! I've tried to reproduce this issue, but just couldn't. You can reach the official Okta support and give them x-okta-request-id and the error object. They will pass this downstream to the team in charge of this functionality.

[paullschock]

@bogdanprodan-okta thank you for the response and related PR. I am not surprised you cannot reproduce the issue as I could only reproduce it for one specific AppID so I think this is a bug that only occurs under some very specific set of conditions. I am going to see if we can adapt our code to not include priority *Recommend users grab the latest tag for the provider and see if that makes a difference as my test results for the affected appId are exactly as described by @faurel (i.e. when using curl with an empty body the error did not occur).

@faurel I have a support case that was escalated to the development team and was "resolved" via a one-time script run to clear duplicate priority assignments.

[faurel]

Hi @paullschock, could you share this one-time script or ask OKTA to publish it ?

[paullschock]

Hi @paullschock, could you share this one-time script or ask OKTA to publish it ?

This is something support worked on so its nothing I can share. I'd suggest you work with Okta support sharing the same details suggested earlier (x-okta-request-id and the error object) and they'll be able to resolve for you in the same one-off manner.

[bogdanprodan-okta]

Yes, Okta support reached to me as well and they've created an internal Jira issue and currently working to solve it. This has nothing to do with the provider itself, but rather the Okta backend logic.