terraform-provider-okta icon indicating copy to clipboard operation
terraform-provider-okta copied to clipboard

Oauth app changes reset policy_assignment

Open dorik84 opened this issue 1 year ago • 7 comments

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v1.5.7

Affected Resource(s)

resource "okta_app_oauth" resource "okta_app_access_policy_assignment" resource "okta_app_signon_policy"

Terraform Configuration Files

terraform {
  required_providers {
    okta = {
      source = "okta/okta"
      version = "~> 4.4.2"
    }
  }
}


resource "okta_app_oauth" "test_app" {
  accessibility_self_service = false
  auto_key_rotation          = true
  auto_submit_toolbar        = false
  consent_method             = "TRUSTED"
  grant_types = [
    "authorization_code"
  ]
  hide_ios     = false
  hide_web     = false
  issuer_mode  = "ORG_URL"
  label        = "test DELETE"
  login_uri    = "https://random.ca"
  login_mode   = "SPEC"
  login_scopes = ["openid" ]
  omit_secret  = false
  redirect_uris = [
    "http://localhost:8080/callback"
  ]
  refresh_token_leeway   = 0
  refresh_token_rotation = "STATIC"
  response_types = [
    "code"
  ]
  status                     = "ACTIVE"
  token_endpoint_auth_method = "client_secret_basic"
  type                       = "web"
  user_name_template         = "$${source.login}"
  user_name_template_type    = "BUILT_IN"
  wildcard_redirect          = "DISABLED"

  groups_claim {
    name  = "groups"
    type  = "EXPRESSION"
    value = "Arrays.isEmpty(Arrays.toCsvString(Groups.startsWith(\"active_directory\",\"\",100))) ? Groups.startsWith(\"OKTA\",\"\",100) : Arrays.flatten(Groups.startsWith(\"OKTA\",\"\",50),Groups.startsWith(\"active_directory\",\"\",50))"
  }
}

resource "okta_app_signon_policy" "test_desired_policy" {
  name        = "desired_policy"
  description = "Policy I want"
}

resource "okta_app_access_policy_assignment" "test_desired_policy_assignment" {
  app_id     = okta_app_oauth.test_delete.id
  policy_id  = okta_app_signon_policy.desired_policy.id
}

Debug Output

Panic Output

Expected Behavior

Remote Configuration must match local state

Can this be done in the Admin UI?

No

Can this be done in the actual API call?

I don't know

Actual Behavior

When you apply changes to any of the okta_app_oauth resource config params, Authentication Policy of the app resets to a default "Any two factors" policy. Not the one which is assigned before inokta_app_access_policy_assignment resource

Steps to Reproduce

  1. Deploy the code above in Terraform Configuration Files section through terraform apply cmd.
  2. Once deployed go to Okta UI admin dashboard and get into your new application test DELETE -> Sign On tab -> Scroll down to User authentication section -> verify that Authentication policy value is "desired_policy" as expected.
  3. After new resources deployed, go to "okta_app_oauth" "test_app" resource and change login_uri from "https://random.ca" to "https://random.com".
  4. Apply changes via terraform apply cmd. In plan part you will see the expected changes related to login_uri value.
  5. Once applied, go to Okta UI admin dashboard and get into your new application test DELETE
  6. Go to Sign On tab. Scroll to the very end. In the User authentication section you will see that Authentication policy value is "Any two factors" not "desired_policy" as expected.

Important Factoids

References

dorik84 avatar Nov 17 '23 18:11 dorik84

I believe this is a bug across all okta_app_* resources https://github.com/okta/terraform-provider-okta/issues/1742

exitcode0 avatar Nov 18 '23 04:11 exitcode0

OKTA internal reference https://oktainc.atlassian.net/browse/OKTA-669839

duytiennguyen-okta avatar Nov 21 '23 17:11 duytiennguyen-okta

Just checking on the status of this issue and to see if we have even a ballpark timeframe for an expected fix. This is currently impacting a pending upgrade to the OIE for our production tenant. Thanks!

fporcaro avatar Jan 23 '24 18:01 fporcaro

@fporcaro - This bug shouldn't be a blocker for your upgrade to OIE you can update your terraform app definitions to include the correct policy_assignment values and then proceed with your OIE upgrade, which should allow you to work around this bug

exitcode0 avatar Jan 23 '24 23:01 exitcode0

@exitcode0 Sorry, I actually just got some time to run through a sample code in one of our projects and this actually is a blocker. So if you look at the original post by @dorik84, he shows that he is making the policy assignment in his sample code and when you run the code initially, you get the assignment made to his desired policy. Then if you make an unrelated change to the application (like change the label) and re-run the terraform, you will see that even though the policy assignment is in place, the assignment gets reset to the default policy. We have no way of deterministically assigning the correct policy throughout the lifetime of an application and any time an unrelated change comes down and our pipeline executes, our authorization policy gets reset.

In our case the we are looking up the appropriate policy by name when doing the assignment, so if I were to update @dorik84's code for our situation, it would look like this:

terraform {
  required_providers {
    okta = {
      source = "okta/okta"
      version = "~> 4.6.3"
    }
  }
}


resource "okta_app_oauth" "test_app" {
  accessibility_self_service = false
  auto_key_rotation          = true
  auto_submit_toolbar        = false
  consent_method             = "TRUSTED"
  grant_types = [
    "authorization_code"
  ]
  hide_ios     = false
  hide_web     = false
  issuer_mode  = "ORG_URL"
  label        = "test DELETE"
  login_uri    = "https://random.ca"
  login_mode   = "SPEC"
  login_scopes = ["openid" ]
  omit_secret  = false
  redirect_uris = [
    "http://localhost:8080/callback"
  ]
  refresh_token_leeway   = 0
  refresh_token_rotation = "STATIC"
  response_types = [
    "code"
  ]
  status                     = "ACTIVE"
  token_endpoint_auth_method = "client_secret_basic"
  type                       = "web"
  user_name_template         = "$${source.login}"
  user_name_template_type    = "BUILT_IN"
  wildcard_redirect          = "DISABLED"

  groups_claim {
    name  = "groups"
    type  = "EXPRESSION"
    value = "Arrays.isEmpty(Arrays.toCsvString(Groups.startsWith(\"active_directory\",\"\",100))) ? Groups.startsWith(\"OKTA\",\"\",100) : Arrays.flatten(Groups.startsWith(\"OKTA\",\"\",50),Groups.startsWith(\"active_directory\",\"\",50))"
  }
}

resource "okta_app_access_policy_assignment" "test_desired_policy_assignment" {
  app_id     = okta_app_oauth.test_delete.id
  policy_id  = data.okta_policy.custom_apps_policy.id
}

data "okta_policy" "custom_apps_policy" {
  name = "Custom App Policy"
  type = "ACCESS_POLICY"
}

fporcaro avatar Feb 09 '24 18:02 fporcaro

@fporcaro @dorik84 I guess the short answer is don't use okta_app_access_policy_assignment and just assign authentication_policy directly. See Example. The long answer is okta_app_access_policy_assignment were being put in with much thought of how it would impact okta_app_*.authentication_policy as a whole. Let me know if that works with your issue

duytiennguyen-okta avatar May 17 '24 14:05 duytiennguyen-okta

This issue is stale because it has been open 60 days with no activity. Comment or this will be closed in 35 days

github-actions[bot] avatar Jun 22 '24 00:06 github-actions[bot]