okta / terraform-provider-okta

A Terraform provider to manage Okta resources, enabling infrastructure-as-code provisioning and management of users, groups, applications, and other Okta objects.
https://registry.terraform.io/providers/okta/okta
Mozilla Public License 2.0
259 stars 209 forks source link

DOCUMENTATION: resource okta_app_saml fails with error, subDomain: The field cannot be left blank #1748

Open jeffreymlewis opened 1 year ago

jeffreymlewis commented 1 year ago

Community Note

Description

Please update documentation for terraform resource okta_app_saml to include the required "subDomain" field when using "pre-configured" apps. (I'm not sure if all pre-configured apps need this, but the "snowflake" app definitely does.)

New or Affected Resource(s)

Potential Terraform Configuration

I tried to create an Okta application using preconfigured_app as shown below.

resource "okta_app_saml" "snowflake" {
  preconfigured_app = "snowflake"
  label             = var.okta_app_name
  status            = var.okta_app_enabled ? "ACTIVE" : "INACTIVE"

  auto_submit_toolbar = true
}

This resulted in the following error.

okta_app_saml.snowflake: Creating...
β•·
β”‚ Error: failed to create SAML application: the API returned an error: Api validation failed: subDomain. Causes: errorSummary: subDomain: The field cannot be left blank
β”‚ 
β”‚   with okta_app_saml.snowflake,
β”‚   on main.tf line 6, in resource "okta_app_saml" "snowflake":
β”‚    6: resource "okta_app_saml" "snowflake" {

Adding the following to my okta_app_saml resource resolved the issue. This is not documented anywhere that I could find. I recommended updating the documentation for this terraform resource, maybe to include an example setting the subDomain field.

  app_settings_json = jsonencode({
    subDomain = var.snowflake_account_name
  })

References

https://registry.terraform.io/providers/okta/okta/latest/docs/resources/app_saml

exitcode0 commented 1 year ago

To my knowledge, the content that is acceptable and/or required in app_settings_json is defined by the author of the preconfigured_app (OIN app), in this case snowflake

I'm not sure how the Terraform provider could account for this without the Upstream API adding some sort of new functionality. e.g the Upstream Okta API creates a new endpoint that returns the app_settings_json schema for a given preconfigured_app

jeffreymlewis commented 1 year ago

Ah I see what you mean. Not sure how you could solve that issue, short of letting each OIN provider update the terraform documentation (which probably isn't feasible).

For the record, I discovered what I needed for the Snowflake app, by creating an app integration in the console, importing it into terraform, then dumping the config using terraform state pull.

exitcode0 commented 1 year ago

For the record, I discovered what I needed for the Snowflake app, by creating an app integration in the console, importing it into terraform, then dumping the config using terraform state pull.

I've adopted a similar workflow for OIN apps, I use an Okta trail account instead to avoid using my production account(s)

I've raised an Okta idea about this - https://ideas.okta.com/app/#/case/189232

exitcode0 commented 1 year ago

Some nerdsniped sleuthing later, it appears that this endpoint gives some of the data required oinmanager.okta.com/api/v1/catalog/integrations/<preconfigured_app_name> I think this endpoint might be what we need, but I think its only internal facing, perhaps its been replaced by the above APIs Β―\(ツ)/Β― example.okta.com/api/internal/app/catalogue/v2

jefftaylor-okta commented 1 year ago

@jeffreymlewis Thank you for logging this issue! We are working on making the schemas of the OIN apps public. However, there are 7,000+ apps in the Okta Integration Network, so this will take some time. πŸ˜… Currently we are focused on our top apps. Please stay tuned as we make more progress in this area.

duytiennguyen-okta commented 1 year ago

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