okta_policy_rule_signon identity_provider variable causing API error Invalid condition type specified: identityProvider

[mnovitsk]

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.0.10
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v3.75.1
+ provider registry.terraform.io/okta/okta v3.25.0

Affected Resource(s)

• resource.okta_policy_rule_signon
• resource.okta_policy_signon

Terraform Configuration Files

resource "okta_policy_signon" "mnovitsk_policy" {
  name        = "mnovitsk_signon_policy"
  description = "Signon Policy for certain users"
  priority    = 1
  status      = "INACTIVE"
  groups_included = [
    resource.okta_group.mnovitsk_test.id
  ]
  depends_on = [
    resource.okta_group.mnovitsk_test
  ]
}

resource "okta_policy_rule_signon" "mnovitsk_policy_rule" {
  policy_id          = resource.okta_policy_signon.mnovitsk_policy.id
  status             = "INACTIVE"
  name               = "mnovitsk_signon_policy_rule"
  authtype           = "ANY"
  access             = "ALLOW"
  primary_factor     = "PASSWORD_IDP"
  network_connection = "ANYWHERE"
  session_idle       = 120 # 2 hour idle session
  session_lifetime   = 720 # 12 hour session lifetime
  depends_on = [
    resource.okta_policy_signon.mnovitsk_policy
  ]
}

Debug Output

Panic Output

Expected Behavior

Create a Global Session Policy (resource.okta_policy_signon) with a Policy Rule (resource.okta_policy_rule_signon)

Actual Behavior

Terraform errors out when trying to apply the configuration. It automatically supplies an identity_provider = "ANY" variable, even if it is not manually supplied, and then errors out. I encounter the same error when manually supplying identity_provider = "ANY" in the Terraform resource configuration.

Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # okta_policy_rule_signon.mnovitsk_policy_rule will be created
  + resource "okta_policy_rule_signon" "mnovitsk_policy_rule" {
      + access              = "ALLOW"
      + authtype            = "ANY"
      + id                  = (known after apply)
      + identity_provider   = "ANY"
      + mfa_remember_device = false
      + mfa_required        = false
      + name                = "mnovitsk_signon_policy_rule"
      + network_connection  = "ANYWHERE"
      + policy_id           = (known after apply)
      + primary_factor      = "PASSWORD_IDP"
      + risc_level          = "ANY"
      + session_idle        = 120
      + session_lifetime    = 720
      + session_persistent  = false
      + status              = "INACTIVE"
    }

  # okta_policy_signon.mnovitsk_policy will be created
  + resource "okta_policy_signon" "mnovitsk_policy" {
      + description     = "Signon Policy for certain users"
      + groups_included = [
          + "<okta_group_id>",
        ]
      + id              = (known after apply)
      + name            = "mnovitsk_signon_policy"
      + priority        = 1
      + status          = "INACTIVE"
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

okta_policy_signon.mnovitsk_policy: Creating...
okta_policy_signon.mnovitsk_policy: Creation complete after 0s [id=00p3k04nmpYoSa3eq1d7]
okta_policy_rule_signon.mnovitsk_policy_rule: Creating...
╷
│ Error: failed to create sign-on policy rule: failed to create policy rule: the API returned an error: Api validation failed: conditions. Causes: errorSummary: conditions: Invalid condition type specified: identityProvider.
│ 
│   with okta_policy_rule_signon.mnovitsk_policy_rule,
│   on main.tf line 60, in resource "okta_policy_rule_signon" "mnovitsk_policy_rule":
│   60: resource "okta_policy_rule_signon" "mnovitsk_policy_rule" {
│ 
╵
Releasing state lock. This may take a few moments...

Steps to Reproduce

1. terraform apply

Important Factoids

References

I checked the Terraform Provider Documentation: https://registry.terraform.io/providers/okta/okta/latest/docs/resources/policy_rule_signon#identity_provider and it states that "Use of identity_provider requires a feature flag to be enabled.", but I do not see a flag in the tenant features related to this setting.

I am able to create Global Session Policies and Policy Rules via the UI with no issues, but attempting to create these resources via Terraform does not work. The policy itself is successfully created via Terraform, but there are no policy rules associated with it.

• #1028 : I also am experiencing a similar issue when trying to assign a specific priority to a new okta_policy_signon resource. I'm currently just providing priority = 1 to get around this issue for now, but it is going to cause larger problems when trying to declare and configure multiple sign on policies.

[monde]

@mnovitsk I will look into this, seems like a regression off the just released v3.25.0. Can you pin your provider version to v3.24.0 and let me if you are seeing the correct behavior with that version?

[mnovitsk]

@monde Pinning the Okta Provider version to v3.24.0 removed the identity_provider variable API error, thanks. I tested assigning the priority of the okta_signon_policy to be lower than the default policy and I got an error:

Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # okta_policy_rule_signon.mnovitsk_policy_rule will be created
  + resource "okta_policy_rule_signon" "mnovitsk_policy_rule" {
      + access              = "ALLOW"
      + authtype            = "ANY"
      + id                  = (known after apply)
      + mfa_remember_device = false
      + mfa_required        = false
      + name                = "mnovitsk_signon_policy_rule"
      + network_connection  = "ANYWHERE"
      + policy_id           = (known after apply)
      + primary_factor      = "PASSWORD_IDP"
      + priority            = 1
      + risc_level          = "ANY"
      + session_idle        = 120
      + session_lifetime    = 720
      + session_persistent  = false
      + status              = "INACTIVE"
    }

  # okta_policy_signon.mnovitsk_policy will be created
  + resource "okta_policy_signon" "mnovitsk_policy" {
      + description     = "Signon Policy for certain users"
      + groups_included = [
          + "<okta_group_id>",
        ]
      + id              = (known after apply)
      + name            = "mnovitsk_signon_policy"
      + priority        = 3
      + status          = "INACTIVE"
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

okta_policy_signon.mnovitsk_policy: Creating...
╷
│ Error: failed to create sign-on policy: provided priority was not valid, got: 3, API responded with: 2. See schema for attribute details
│ 
│   with okta_policy_signon.mnovitsk_policy,
│   on main.tf line 47, in resource "okta_policy_signon" "mnovitsk_policy":
│   47: resource "okta_policy_signon" "mnovitsk_policy" {
│ 
╵
Releasing state lock. This may take a few moments...

I realize that this is not necessarily tied to this bug and is more appropriate to #1028 , but can I assume that Okta always sets the Tenant's default policy to be the lowest priority and you cannot create or assign any sign on policies to be lower than the default policy?

[monde]

@mnovitsk I'm trying to get a bug fix out today and will address both the original bug and try to see if there is a fix and/or flexibility dealing with the error in v3.24.0 you are seeing.

[monde]

@mnovitsk I can't think of a way to deal with the priority issue with out hacking in retries. I've had a similar experience where I thought the API should correctly infer that if I add rules(s) mixed with existing rules, it should be able know the new position of existing rules. Like if there is a default rule which is 1. Then if I add two new rules, one priority 1, and the other priority 3; thinking that that the API will flexibly make the existing rule be priority 2. I just had to run my apply a couple of times.

Here, I ran into that when I was working on enrollment policies.

[monde]

I have a fix queued up in PR #1081 and am waiting for a colleague to review it before releasing.

[monde]

v3.25.1 is available in the terraform registry

[monde]

@mnovitsk I reopened this issue. I had to revert part of this change and it was released as v3.28.0 https://github.com/okta/terraform-provider-okta/releases/tag/v3.28.0 . Can you take a moment if this issue would occur again for you? Feel free to close the issue if you are good.

[miguelpuiggarcia]

Hi @monde This issue is happening again with version v3.28.0 if this helps Error: failed to update sign-on policy rule: the API returned an error: Api validation failed: conditions. Causes: errorSummary: conditions: Invalid condition type specified: identityProvider.

[monde]

@miguelpuiggarcia @mnovitsk I'll make it a priority to get to the bottom of this today and do a patch release ASAP

[lucascantor]

@monde to confirm, is this bug still expected to impact today's new 3.29.0 release?

[monde]

@lucascantor I've not had a chance to look at this one yet, nothing related to it is in v3.29.0

[tim-fitzgerald]

Just adding my voice here. Experiencing this on 3.29.0. If I can provide any useful info @monde please let me know.

[Mrorya]

This bug is still present in 3.30.0

[lucascantor]

Looks like this bug is still present in 3.31.0 as well.

I'm sorry I don't understand the nature of the root cause to offer a fix ☹️ Is there perhaps a workaround that allows use of okta_policy_rule_signon resources until this is fixed though?

We're stuck on 3.27.0 because of this, and can't make use of other important bug fixes in newer releases.

I imagine nearly every Okta customer using the Okta Terraform provider also has okta_policy_rule_signon resources, putting them in a similar predicament.

[tmatilai]

Is there perhaps a workaround that allows use of okta_policy_rule_signon resources until this is fixed though?

Can't test it now, but ignoring the attribute should work. Something like:

resource "okta_policy_rule_signon" "example" {
  lifecycle {
    ignore_changes = [identity_provider]
  }
  # ...
}

We're stuck on 3.27.0 because of this, and can't make use of other important bug fixes in newer releases.

By splitting the Okta configurations into multiple root modules, you might be able to use the newer version where needed, while pinning down the version only where you are affected by a certain bug.

[tmatilai]

Can't test it now, but ignoring the attribute should work

And if it doesn't work in initial creation of the resource, at least by creating the rule manually and then importing to the state, the ignore_changes should do its job.

[lucascantor]

@tmatilai thanks so much for the advice 🙇🏼

[monde]

This one is still on my todo list. I'm on vacation for a week and can give it priority when I get back.

[monde]

"bug(s) with resources having a priority setting" #1198

[tmatilai]

@monde while the problem with priority bug is real and annoying, IMHO the main issue here is the identityProvider attribute (as stated in the subject). To my understanding it's behind a feature flag in the Okta tenant configurations, and without enabling, the API doesn't like to see it used. Right?

Would removing the default value be sufficient fix? Or should the API be changed to ignore the attribute?

[lucascantor]

I can confirm adding

lifecycle {
    ignore_changes = [identity_provider]
}

resolves my issue, allowing me to use 3.31.0.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days

[lucascantor]

This bug still exists. Commenting to prevent auto-closure.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days

[lucascantor]

Not stale

[monde]

"0" zero value integers was fixed in v3.44.0 release. I'm not sure that will benefit anything here. Looking for feedback.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days