terraform-provider-okta
terraform-provider-okta copied to clipboard
okta
Add attribute to okta_app_signon_policy to create a 'Catch All' rule that's 'DENY'
okta_app_signon_policy creates a default 'Catch All' rule. Once such a rule is created, it's difficult to change anything about it with terraform since the codebase implementing okta_app_signon_policy_rule is designed to work with mutable rules vs. all the restrictions associated with the 'Catch All' rule.
If you could add an attribute to okta_app_signon_policy (catchAll = "DENY"), then okta_app_signon_policy could create policies with 'Catch All' being a noop - the mutable rules could be used for everything else. As it stands, I have to go and manually configure the 'Catch All' rules to 'DENY' while using terraform scripts to configure all the other rules.
I strongly agree with this, given Okta's official instruction when enforcing Device Trust is to do exactly this.
Currently, we're forced to implement a regular DENY rule at the lowest priority above the catch-all rule, since importing the catch-all rule into Terraform state requires painful bureaucracy and toil in our org.
@monde I recently upgraded provider version to 3.34.0 and ran into similar issues managing the default Catch-all rule. The primary reason behind upgrading the provider version was to be able to explicitly create and associate app_signon_policy resources to applications when the app is created. This works, but it seems that the catch-all rule is not able to properly be managed by Terraform after importing the resource.
The Okta Terraform Provider docs (https://registry.terraform.io/providers/okta/okta/latest/docs/resources/app_signon_policy_rule and https://registry.terraform.io/providers/okta/okta/3.34.0/docs/resources/app_signon_policy_rule) both state that you can manage the catch-all rule by manually importing the rule, but the provider throws errors when trying to set the rule to "DENY" after importing it.
It wouldn't even attempt to apply if the name, priority, or constraints had been altered. Setting all of the values to be the same as the default settings (determined via Console and API calls), except for changing access from "ALLOW" to "DENY", would still result in an error being thrown.
Being able to truly manage the catch-all rule would be useful. Being able to automatically set it to deny by default would be even better.
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
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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
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
also worth mentioning that the docs imply that you could import into terraform state and then modify the access, but as mentioned above that gives an error due to modifying constraints.
A default or Catch-all Rule sign-on policy rule can be imported and managed as a custom rule. The only difference is that these fields are immutable and can not be managed:
network_connection,network_excludes,network_includes,platform_include,custom_expression,device_is_registered,device_is_managed,users_excluded,users_included,groups_excluded,groups_included,user_types_excludedanduser_types_included.
that is, access is not in that list
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
This would be a nice feature to have, we have resorted to simply ignoring the catchall and creating our own that serves the same "any request" purpose.
implicit_deny = {
name = "Implicit Deny"
priority = 98
access = "deny"
managed = false
registered = false
}
