Datasource for app schema(s)

[exitcode0]

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

---

Preamble

There is an existing issue for this that was a victim of the old stalebot - #1195
I decided to create this issue rather than commenting on the now closed issue as a comment on the now closed issue relies on people not missing the Github Notification for the comment

Prior Context

Provisioning applications can mutate their base or custom schema when provisioning is enabled for the first time
This leads to a few problems for the provider (more details in #1805):

• Duplicate config may or may not produce a duplicate result
• difficulty in accounting for this non-determinism in Multiple workspace deployment pipelines

Current Behaviour

Currently to work around the state of an application's schema being unknowable I must use terraform.workspace or okta_app_saml.features to infer the state of schrodinger's app schema in bodgy workarounds

Current Workarounds

Click to expand

locals {
  exampleApp-to_app = flatten([
    { id = "username", expression = "user.login" },
    { id = "email", expression = "user.email" },
    (
      terraform.workspace != "production" ? [] :
      [
        { id = "firstName", expression = "user.firstName" },
        { id = "lastName", expression = "user.lastName" }
      ]
    )
  ])
}
resource "okta_profile_mapping" "exampleApp-to_app" {
  source_id          = data.okta_user_profile_mapping_source.user.id
  target_id          = okta_app_saml.exampleApp.id
  delete_when_absent = false

  dynamic "mappings" {
    for_each = local.exampleApp-to_app
    content {
      id         = mappings.value.id
      expression = mappings.value.expression
      # push_status = (contains(okta_app_saml.exampleApp.features, "PUSH_PROFILE_UPDATES") ? "PUSH" : "DONT_PUSH")
      # push_status = terraform.workspace == "production" ? "PUSH" : "DONT_PUSH"
    }
  }
}

Alternative solutions

Importing the Attributes

Importing the attributes is a non-starter because while this will work for the application at hand.
If a colleague ever duplicates your configuration to create another app instance, their deployment will fail due to the attempted modification of the application base schema

Proposed Solution

To work around this behaviour of OIN applications, the provider should include a DataSource that facilitates checking the application schema during a Terraform plan or Terraform apply

New or Affected Resource(s)

• data okta_app_user_base_schema
• data okta_app_user_custom_schema
• data okta_app_user_schema

Potential Terraform Configuration

Click to expand

data "okta_app_user_base_schema" "exampleApp" { app_id = "1234" }
data "okta_app_user_custom_schema" "exampleApp" { app_id = "1234" }
locals {

  exampleApp-to_app = [
    { id = "username", expression = "user.login" },
    { id = "email", expression = "user.email" },
    { id = "firstName", expression = "user.firstName" },
    { id = "lastName", expression = "user.lastName" },
  ]
}
resource "okta_profile_mapping" "exampleApp-to_app" {
  source_id          = data.okta_user_profile_mapping_source.user.id
  target_id          = okta_app_saml.exampleApp.id
  delete_when_absent = false

  dynamic "mappings" {
    for_each = [
      for attr in local.exampleApp-to_app : attr if
      contains(data.okta_app_user_base_schema.attributes, attr.id) ||
      contains(data.okta_app_user_custom_schema.attributes, attr.id)
    ]
    content {
      id         = mappings.value.id
      expression = mappings.value.expression
      # push_status = (contains(okta_app_saml.exampleApp.features, "PUSH_PROFILE_UPDATES") ? "PUSH" : "DONT_PUSH")
      # push_status = terraform.workspace == "production" ? "PUSH" : "DONT_PUSH"
    }
  }
}

References

• datasource app_user_base_schema_property & app_user_schema_property #1195

[duytiennguyen-okta]

@exitcode0 so this is related to the OIN app? Similar to #1805? Or you just want to expose the schema through datasource? I am a bit confused?

[github-actions]

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

[exitcode0]

@exitcode0 so this is related to the OIN app? Similar to #1805? Or you just want to expose the schema through datasource? I am a bit confused?

@duytiennguyen-okta It is related, but I guess this is for a slightly different ask
If I can't create the application in its final state, it would be good to be able to determine if the application is in the pre or post schema mutation

[duytiennguyen-okta]

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