Add brand_id as attribute reference for okta_domain resource

[chad-larsen-rapid]

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

Description

The Okta Management API does not have a true Create or Delete option for brands. This leads to issues when attempting to manage brands, domains, and email_domains with Terraform. Example issue.

It appears that a brand is automatically created when an okta_domain resource is created. Also, the Custom Domains API includes a brandID in its response value:

{
  "domains": [
    {
      "brandId": "bndul904tTZ6kWVhP0g3",
      "certificateSourceType": "MANUAL",
      "dnsRecords": [],
      "domain": "login.example.com",
      "id": "OcDz6iRyjkaCTXkdo0g3",
      "publicCertificate": {},
      "validationStatus": "VERIFIED",
      "_links": {}
    }
  ]
}

I think a potential workaround could be to add brand_id as an attribute reference for okta_domain resources. This will enable users to "create" a brand when creating an okta_domain and then reference it's value in other resources like okta_email_domain.

New or Affected Resource(s)

• okta_domain
• okta_email_domain
• okta_email_customizations

Potential Terraform Configuration

resource "okta_domain" "public" {
  name                                = "www.example.com" 
  certificate_source_type = "OKTA_MANAGED"
}

resource "okta_email_domain" "example" {
  brand_id     = okta_domain.public.brand_id
  domain       = "example.com"
  display_name = "test"
  user_name    = "paul_atreides"
}

References

• https://developer.okta.com/docs/api/openapi/okta-management/management/tag/CustomDomain/
• resource okta_brand fails to apply #1130

[duytiennguyen-okta]

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

[chad-larsen-rapid]

To add to this, it would also be helpful to return the theme_id with the domain. Currently, I have to:

1. Create a domain with a targeted deploy: terraform apply -target module.example.okta_domain.public
2. Gather the brand_id and theme_id that are created with the domain - in web console or programmatically
3. Update the brand_id in related resources, eg, okta_email_domain, okta_email_customization, okta_theme
4. Import the theme: terraform import module.example.okta_theme.main brand_id/theme_id
5. Finally, I can perform the full apply to deploy brand-related resources

This is a very frustrating development process and inhibits CI/CD endeavors for your customers. Please consider refactoring this or, at the very least, providing workarounds.

[monde]

@chad-larsen-rapid okta updated the management API for brands to be fully CRUD and @duytiennguyen-okta has implemented that in #1677 which will be in the next release. I like to see if the updated behavior benefits your use case. In general, making composite resources and data sources (e.g. adding theme_id to domain) is a bit of anti pattern in TF where Hashicorp suggests resources should focus on a single API object https://developer.hashicorp.com/terraform/plugin/best-practices/hashicorp-provider-design-principles . If you can get access to the theme_id from resources/datasources we already provide, that is the best practice in the TF config.

[the-Fitz]

Thanks for the update @monde. I agree that my proposal was a bit of an anti-pattern and was suggested only as a workaround because it was unclear what the intent for the programmatic control of brands is supposed to be. Right now the brand resources that are heavily coupled in the web UI/console don't seem to be connected at all in the SDK. If brands and themes are fully enabled for CRUD, that will likely be a much better long term approach.

Does that mean that Okta intends for the management of brands, and their related resources, to look something like this in the future?

resource "okta_brand" "example" {
  ...
}

resource "okta_theme" "example" {
  brand_id = okta_brand.example.id
  ...
}

resource "okta_domain" "example" {
  brand_id = okta_brand.example.id
  ...
}

resource "okta_domain" "example" {
  brand_id = okta_brand.example.id
  ...
}

resource "okta_email_domain" "example" {
  brand_id = okta_brand.example.id
  ...
}

resource "okta_email_customization" "example" {
  brand_id = okta_brand.example.id
  ...
}

[duytiennguyen-okta]

Yes that is the general idea. And for reference, email_domain already allow for brand_id input when create and update. Email customization however does not allow brand_id to be update from the API

[duytiennguyen-okta]

Close with #1685