okta/terraform-provider-okta

Terraform Okta provider

Terraform Provider for Okta

The Terraform Okta provider is a plugin for Terraform that allows for the full lifecycle management of Okta resources. This provider is maintained internally by the Okta development team.

Examples

All the resources and data sources has one or more examples to give you an idea of how to use this provider to build your own Okta infrastructure. Provider's official documentation is located in the official terraform registry, or here in form of raw markdown files.

Development Environment Setup

The sections below will guide you through the requirements, upgrading, getting started, building with and contributing to the Okta Terraform Provider.

Requirements

• Terraform 0.14.0 or newer (to run acceptance tests)
• Go (to build the provider plugin)

Upgrade

If you have been using version 3.x of the Okta Terraform Provider, please upgrade to the latest version to take advantage of all the new features, fixes, and functionality. Please refer to this Upgrade Guide for guidance on how to upgrade to version 4.x. Also, please check our Releases page for more details on major, minor, and patch updates.

Quick Start

If you wish to work on the provider, you'll first need Go installed on your machine (please check the requirements before proceeding).

Note: This project uses Go Modules making it safe to work with it outside your existing GOPATH. The instructions that follow assume a directory in your home directory outside the standard GOPATH (i.e $HOME/development/terraform-providers/).

Clone repository to: $HOME/development/terraform-providers/

$ mkdir -p $HOME/development/terraform-providers/; cd $HOME/development/terraform-providers/
$ git clone [email protected]:okta/terraform-provider-okta.git
...

Enter the provider directory and run make tools. This will install the needed tools for the provider.

$ make tools

To compile the provider, run make build. This will build the provider and put the provider binary in the $GOPATH/bin directory.

$ make build
...
$ $GOPATH/bin/terraform-provider-okta
...

Testing the Provider

In order to test the provider, you can run make test.

$ make test

In order to run the full suite of Acceptance tests, run make testacc.

Note: Acceptance tests create real resources, and often cost money to run. Please read Running an Acceptance Test in the contribution guidelines for more information on usage.

$ make testacc

Using the Provider

To use a released provider in your Terraform environment, run terraform init and Terraform will automatically install the provider. To specify a particular provider version when installing released providers, see the Terraform documentation on provider versioning .

To instead use a custom-built provider in your Terraform environment (e.g. the provider binary from the build instructions above), follow the instructions to install it as a plugin. After placing the custom-built provider into your plugins' directory, run terraform init to initialize it.

For either installation method, documentation about the provider specific configuration options can be found on the provider's website.

Contributing

Terraform is the work of thousands of contributors. We really appreciate your help!

We have these minimum requirements for source code contributions.

Bug fix pull requests must include:

• Terraform Plugin Acceptance Tests.

Pull requests with new resources and data sources must include:

• Signed Okta Individual Contributor License Agreement emailed to [email protected]
• Implemented with the Terraform Plugin Framework (not Terraform Plugin SDKv2 )
• Make Okta API calls with the okta-sdk-golang v3 client
• Include Terraform Plugin Acceptance Tests

Please see the contribution guidelines for additional information about making contributions to the Okta Terraform Provider.

Issues on GitHub are intended to be related to the bugs or feature requests with provider codebase. See Plugin SDK Community and Discuss forum for a list of community resources to ask questions about Terraform.

terraform-provider-okta's Issues

terraform validate should fail if redirect_uris contains a fragment

@jeremie0 commented on Jul 17, 2019, 5:12 PM UTC:

Is your feature request related to a problem? Please describe.
If we configure a okta_app_oauth resource as:

resource "okta_app_oauth" "sample123" {
  label       = "sample123"
  type        = "browser"
  grant_types = ["implicit"]
  redirect_uris              = ["http://localhost", "http://localhost:3000", "http://dev-api.company.com/testapi/v1passive/#/request", ]
  response_types             = ["token", "id_token"]
  omit_secret                = true
  token_endpoint_auth_method = "none"
  groups                     = ["${data.okta_group.everyone.id}"]
}

A terraform validate passes:

$ terraform validate
Success! The configuration is valid.

but when we terraform apply we get an error back from Okta:

Error: The API returned an error: Api validation failed: redirect_uris. Causes: errorSummary: redirect_uris: ''redirect_uris'' must not contain a fragment identifier.

Describe the solution you'd like
It would be great if terraform validate could catch this - not allow a redirect_uris that contains a # fragment character.

This issue was moved by noinarisak from articulate/terraform-provider-okta#218.

Allow for creation of other app types

@mikn commented on Nov 11, 2019, 5:42 AM UTC:

Is your feature request related to a problem? Please describe.
Whilst trying to provision a "Microsoft RDP (MFA)" type application, I find that there is no resource that describes an application that would support those settings.

Describe the solution you'd like
I would like to be able to provision app types outside of Bookmark/OAuth/SAML/Three-field/Secure Password and SWA.

Additional context
Browsing the source code, I cannot find any resource that implements the CreateApplication() interface of the general application struct. I also do not find any app resource that provides the "MFA_AS_SERVICE" as a sign-on type in the Okta provider.

Should we implement a generic okta_app_custom which can take more settings, kind of matching the CreateApplication function (found here: https://github.com/okta/okta-sdk-golang/blob/master/okta/application.go#L121)?
Another alternative is to implement a specific resource for rdp_mfa and/or MFA_AS_SERVICE?

For reference, this is the API response for the Microsoft RDP (MFA) application type:

  {
    "id": "{REDACTED}",
    "name": "mfa_rdp",
    "label": "Microsoft RDP (MFA)",
    "status": "ACTIVE",
    "lastUpdated": "2019-11-08T05:38:40.000Z",
    "created": "2019-11-08T05:38:39.000Z",
    "accessibility": {
      "selfService": false,
      "errorRedirectUrl": null,
      "loginRedirectUrl": null
    },
    "visibility": {
      "autoSubmitToolbar": false,
      "hide": {
        "iOS": true,
        "web": true
      },
      "appLinks": {
        "mfaAppHelpLink": true
      }
    },
    "features": [],
    "signOnMode": "MFA_AS_SERVICE",
    "credentials": {
      "userNameTemplate": {
        "template": "${source.login}",
        "type": "BUILT_IN"
      },
      "signing": {}
    },
    "settings": {
      "app": {
        "mfaAppInstanceId": "{REDACTED}"
      },
      "notifications": {
        "vpn": {
          "network": {
            "connection": "DISABLED"
          },
          "message": null,
          "helpUrl": null
        }
      }
    },
    {REMOVED FOR BREVITY}
  }

This issue was moved by noinarisak from articulate/terraform-provider-okta#318.

Data source searching with Q

@quantumew commented on Aug 6, 2019, 3:58 PM UTC:

Okta's search API for many resources is not super great. If you have two resources Thing and Thing Thing both will appear in a search for ?q=Thing, and you cannot control the order. We can bandage this in the provider by doing some better filtering after making the search requests. We could use a fuzzy algorithm to get the closest match.

This issue was moved by noinarisak from articulate/terraform-provider-okta#232.

Cannot update Default Password Policy configuration

@NeenuAVarghese commented on Sep 29, 2019, 9:13 PM UTC:

Expected Behavior

Should be able to update Default Password Policy configuration

Steps to Reproduce the Problem

resource okta_policy_password "default_password_policy" {
  name                   = "Default Policy"
  description            = "The default policy applies in all situations if no other policy applies."
  groups_included        = ["${var.auth_groups}"]
  question_recovery      = "INACTIVE"
  password_history_count = 4
}

When doing terraform plan, I get that the resource will be updated

 ~ okta_policy_password.default_password_policy
      question_recovery: "ACTIVE" => "INACTIVE"

However, when I do a terraform apply, I get the following error:

1 error(s) occurred:

* okta_policy_password.default_password_policy: 1 error(s) occurred:

* okta_policy_password.default_password_policy: Default Policy is immutable

This issue was moved by noinarisak from articulate/terraform-provider-okta#289.

Failure on undocumented okta_group_rules status "INVALID"

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 0.12.20

Affected Resource(s)

• okta_group_rule

Terraform Configuration Files

resource "okta_group_rule" "parent_assignments" {
  name              = "00g2zzwlxcyz77tF0297:<redacted>"
  group_assignments = ["00g2zym3chkeQFWKi297"]
  expression_type   = "urn:okta:expression:1.0"
  expression_value  = "isMemberOfGroup(\"00g2zzwlxcyz77tF0297\")"
}

Debug Output

https://gist.github.com/tgoodsell-tempus/07211d3c4e79649c3d29a7c609544adc

Expected Behavior

This is not "expected", however the status "INVALID" is undocumented, in that I could not find a reference to it in the okta group rules reference.

The "INVALID" status seems to occur when the one or more of the groups in the group_assignments section is deleted, this is accompanied with the following status in the object metadata:
JSON Response of GET on group rule: 'allGroupsValid': False

An invalid rule can only be deleted, as it's no longer allowed to be change or cycled using the update, activate, and deactivate ops. Generally, I've seen this occur for us when a group manually managed or managed separately was deleted before the rule could be dealt with accordingly.

IMO the behavior should follow the "terraform taint" behavior, in that the rule is deleted and then dealt with according to the contents of the TF code.

I'm not sure of the specific "best practice" of how to deal with this type of situation from a terraform standpoint, as I was attempting to remove/delete the rule in my example here.

Actual Behavior

The API validation failed during the updateRuleStatus operation, as there is no handling ready for when the status is returned as "INVALID".

Steps to Reproduce

1. Create valid okta_group_rule resource.
2. Delete the group which is being assigned in the "group_assignments" field.
3. Attempt to modify the resource (update or delete).

Important Factoids

We're more prone to this occurring as the vast majority of the groups we use are either "legacy" (non-terraform managed) or mastered in a separate base module + state. Therefore our rules are tied to calling the data.okta_group resources to validate + get necessary information.

References

https://www.terraform.io/docs/providers/okta/r/group_rule.html

https://gist.github.com/tgoodsell-tempus/07211d3c4e79649c3d29a7c609544adc

https://developer.okta.com/docs/reference/api/groups/

Nested Resources

@quantumew commented on Aug 18, 2019, 10:36 PM UTC:

At the advent of this project we followed the pattern of nesting resources. For instance, okta_user takes resources for the user but also takes group_memberships, which is a separate API. In my opinion, this was a mistake, I suggest we deprecate these properties and instead make association resources. This allows for maximal flexibility and prevents issues such as #220 where a single thing can be managed in multiple ways. You do not have to create an okta_user to associate a user with a group (you can use a data source if you like). Admittedly this is verbose but I think it is the right path forward and matches the normal Terraform idiom.

I still need to dig into this to be sure there is no way to support all approaches without any downsides.

It would look like this

resource okta_user me {
    email = "[email protected]"
}

resource okta_group me {
    name = "me"
}

# In some cases we could also do the plural version
resource okta_group_membership me {
    group_id = "${okta_group.me.id}"
    user_id  = "${okta_user.me.id}"
}

This issue was moved by noinarisak from articulate/terraform-provider-okta#248.

okta_group_membership resource

@quantumew commented on Nov 14, 2019, 10:09 PM UTC:

Part of achieving #248 is being able to tie a single user to a single group.

This issue was moved by noinarisak from articulate/terraform-provider-okta#335.

[feature request] shared credentials file

@shantanugadgil commented on Jun 3, 2019, 2:15 PM UTC:

Terraform version: 0.12.0
Provider version: 3.0.0

Would it be possible to add functionality like the "shared credentials file", like that of the AWS provider?

Use case:
When using multiple Okta accounts, in the provider "okta" block, I can just mention the "provider profile" name and then, safely store the actual profile details in my dotfile like, say ~/.terraform_okt_provider.conf.
I know, I can put my settings in the environment, but that limits the settings to a single Okta account, and I have to be always careful of the env variables.

This issue was moved by noinarisak from articulate/terraform-provider-okta#178.

okta_event_hook

@quantumew commented on Sep 6, 2019, 5:36 PM UTC:

Okta Event Hooks are now EA, add a resource for it.

https://developer.okta.com/docs/reference/api/event-hooks/

This issue was moved by noinarisak from articulate/terraform-provider-okta#272.

Missing parameter 'Login initiated by'

@wiciu125 commented on Oct 28, 2019, 9:39 PM UTC:

When configuring OAUTH in terraform there is no option to define Login initiated by parameter.
After successfully creating application the default option for it is "App only".
As a result, when trying to open page by clicking on application in okta an error 404 appears.
To change it to "Either Okta or App" manual action is required from the okta admin page.

The below configuration is for our Grafana

resource "okta_app_oauth" "grafana" {
  label                      = "Grafana"
  type                       = "web"
  grant_types                = ["authorization_code", "implicit"]
  redirect_uris              = ["https://URLTOTHEGRAFANA/login/generic_oauth"]
  response_types             = ["code", "id_token"]
  token_endpoint_auth_method = "client_secret_basic"
  login_uri                  = "https://URLTOTHEGRAFANA"
  hide_web                   = true
}

This issue was moved by noinarisak from articulate/terraform-provider-okta#310.

Provide an Option to PGP Encrypt client_secret

@ryber commented on Jul 1, 2019, 1:22 PM UTC:

Is your feature request related to a problem? Please describe.
Hi, I've noticed that when creating applications that application secrets are stored in state. It would be nice to have an option where that is not kept but left in Okta.

Describe the solution you'd like
Maybe some kind of configuration to not keep secrets in state?

Describe alternatives you've considered
There are various options for encrypting state files including using Terraform Enterprise, but It would be even better if it didn't have the secrets at all to begin with

Thank you for providing this plugin! It's going to make my life sooooooo much better! 💯

This issue was moved by noinarisak from articulate/terraform-provider-okta#202.

User schema properties overwritten

@quantumew commented on Apr 24, 2019, 2:03 PM UTC:

When creating/updating multiple user schema properties we are seeing successful create and update responses but then later when we do a GET, the data is missing. The only way around this is by forcing creates/updates to happen one at a time. This appears to be a race condition in the API.

This issue was moved by noinarisak from articulate/terraform-provider-okta#144.

Email Template customization

@msmrnv1 commented on Sep 27, 2019, 7:29 PM UTC:

Hi,

I am trying to customize the email templates and I would like to reuse the existing HTML templates that I have. It is a pretty long html text. What would be the best approach to do that?

Also, I would like to customize the sender from. Can this be done thru terraform?

This issue was moved by noinarisak from articulate/terraform-provider-okta#286.

"unique" property not supported when updating custom attributes in user schema

Is your feature request related to a problem? Please describe.
I'm trying to enforce uniqueness on 2 custom attributes in my Okta user profile. Currently, it can be done via the Okta UI and by calling POST /api/v1/meta/schemas/user/default by setting "unique": "UNIQUE_VALIDATED"

Describe the solution you'd like
Add the "unique" attribute to user_schema

Support logout uri resource similar to redirect_uri resource

@quantumew commented on Apr 2, 2019, 8:46 PM UTC:

This will allow us to manage URIs in the list while ignoring others.

This issue was moved by noinarisak from articulate/terraform-provider-okta#125.

okta_app structure

@shawnferry commented on May 2, 2019, 7:39 PM UTC:

Conditionally failing okta_app_saml on missing resources only at apply time seems suboptimal.

I think integrated apps should have a different resource. Possibly okta_app_preconfigured, okta_app_integrated, okta_app_from_catalog (selecting catalog because okta says "search catalog" for integrations).

I'm not sure there is a clean answer but I also don't like okta_app_from_catalog_saml, okta_app_from_catalog_oath at all. It seems from a very small test set the auth specific values are not available to change from the UI so it may be fine to just ignore them.

For example (currently works as okta_app_saml)

resource okta_app_from_catalog "greenhouse" {
  preconfigured_app = "greenhouse"
  label             = "greenhouse - TF"

  app_settings_json = <<JSON
  {"subdomain":"terraform-test"}
JSON
}

This issue was moved by noinarisak from articulate/terraform-provider-okta#155.

Okta API Issues

@quantumew commented on Nov 4, 2019, 12:42 AM UTC:

Suddenly our tests are failing and it is for a reason out of our control. I can watch an App get created, return a 200 on the first read, then start 404ing on all subsequent calls, then when I go to debug suddenly the app starts 200ing again. I would guess this is a cache issue on Okta end.

https://support.okta.com/help/s/case/5001Y00001K9bnEQAR

This issue was moved by noinarisak from articulate/terraform-provider-okta#316.

can't opt-in to group user management when importing a group

@joshk0 commented on Jul 24, 2019, 10:26 PM UTC:

Expected Behavior

When I import a group, and it contains some users, and my tf wants to manage the users, a plan should show that the group already has users and compare it against the tf list of users.

Actual Behavior

Until the first apply, or until you adulterate the state to add a non-empty users array, terraform will not show an accurate delta of group users compared to what is in okta.

Steps to Reproduce the Problem

1. create a group with 5 random users, manually
2. create a corresponding tf resource to manage the users of that group. Let's say keep 2 users, burn 3 from the original list, add 3 more
3. import that group from step 1 as the new tf resource
4. terraform plan should show that precise delta mentioned in step2 , however, it will instead say the group is empty and the 5 users from the tf are being added, ignoring whatever the group currently contains

This issue was moved by noinarisak from articulate/terraform-provider-okta#220.

Is this dead?

Should articulate/terraform-provider-okta be the canonical version?

I would propose either removing this or working with the articulate folks to give them access to this repository.

Thanks.

Add support for group/app whitelist for administrative roles

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 administrative roles "Helpdesk Admin" and "Group Admin" support the ability to define a whitelist of groups whose members they're allowed to exercise those functions against.

The "Application Admin" roles also supports a whitelist of applications which functions the same as described above.

My request thusly is either an addition to the admin roles; or if deemed more appropriate, the creation of a new resource which can provide ability to pass these optional whitelists.

This is a bit complicated by the fact the API references the ID of the admin role assignment; so we'd have to ensure that we've got a way to reference what "role" we're trying to whitelist. This may lend itself better to a design pattern of "HELPDESK_ADMIN_WHITELIST", "GROUP_ADMIN_WHITELIST", and "APP_ADMIN_WHITELIST" optional vars in the current resource; where when populated we look for the ID based on what whitelist is being used.

New or Affected Resource(s)

• okta_group_roles
  ** okta_group_roles_group_whitelist
  ** okta_group_roles_app_whitelist

Potential Terraform Configuration

If we go extend current resource route

resource "okta_group_roles" "example" {
  group_id    = "<group id>"
  admin_roles = ["GROUP_ADMIN"]
  group_admin_whitelist = ["<group id>","<group id>"]
}

References

https://developer.okta.com/docs/reference/api/roles/#add-a-group-target-to-a-group-administrator-role-given-to-a-user

https://developer.okta.com/docs/reference/api/roles/#add-a-group-target-to-a-group-administrator-role-given-to-a-user
--->

• #0000

OKTA golang sdk appears to be dead?

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

Since this provider depends on the sdk, I'm a bit concerned if the sdk would become a bottleneck to continued development. That repo appears to be abandoned, with nobody responding to any issues, no recent commits etc.

Is this provider at risk because of the dependency on that abandoned sdk? How can we avoid that?

New or Affected Resource(s)

• okta_XXXXX

Potential Terraform Configuration

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

References

• https://github.com/okta/okta-sdk-golang

Missing Validators

@quantumew commented on Oct 18, 2019, 6:43 PM UTC:

I have noticed a few resources have fields that are restricted in length, for instance, okta_auth_server name attribute, but we don't validate them. This results in errors when applying from Okta's API. We should vet all of our resources and be sure we have all of the simple validators in place.

This issue was moved by noinarisak from articulate/terraform-provider-okta#305.

Why are policy names ForceNew?

@quantumew commented on Oct 18, 2019, 8:28 PM UTC:

I don't see a reason for policy name attributes to be ForceNew. I think this is a remnant of the original iteration of this resource that can be removed.

This issue was moved by noinarisak from articulate/terraform-provider-okta#306.

Missing attribute reference in document for "okta_auth_server_scope"

Copied this over from the articulate repo.

Expected Behavior

There appear to be other attributes exposed by an instance of the "okta_auth_server_scope" resource, such as name, which are not documented.

Actual Behavior

Current attribute reference: https://www.terraform.io/docs/providers/okta/r/auth_server_scope.html#attributes-reference

In the documentation example for claim, it shows the use of a "name" attribute which is not documented in scope: https://www.terraform.io/docs/providers/okta/r/auth_server_claim.html#example-usage.

Additional info

N/A

Okta SDK Panics on bad URI or Token

Expected Behavior

Nice pretty error when consumer provides an invalid Okta URI or Token. We should recover from this panic or even better, the panic never happen!

Actual Behavior

PANIC at the disco.

https://github.com/terraform-providers/terraform-provider-okta/blob/0c1611a960c7c7b35c14ca2edbf99649c970119a/vendor/github.com/okta/okta-sdk-golang/okta/okta.go#L87

Steps to Reproduce

1. configure Okta provider with invalid params
2. run it against anything

App Condition for MFA Enrollment Policy

@jralmaraz commented on Nov 12, 2019, 5:31 AM UTC:

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
In an MFA policy we would be able to list which apps it applies for (or all).

Describe alternatives you've considered
Extend the schema in the following resource
https://github.com/articulate/terraform-provider-okta/blob/master/okta/resource_okta_policy_mfa.go to accept the option of listing all application or just listed Apps.

Additional context
https://help.okta.com/en/prod/Content/Topics/Security/MFA_App_Condition.htm
https://developer.okta.com/docs/reference/api/policy/#multifactor-mfa-enrollment-policy

This issue was moved by noinarisak from articulate/terraform-provider-okta#326.

More Light-handed approach to API calls

@quantumew commented on Jun 11, 2019, 10:33 PM UTC:

There has been concerns about alert fatigue + terraform tripping rate limits in prod. The only real overlap is the user resource. Our prod has only 7 TF managed users so this shouldn't be an issue. We still should have an option to backoff before a 429 if possible. Maybe if the limit is X amount from tripping, cache that, and backoff. This could be problematic but potentially worth adding a config option for.

This issue was moved by noinarisak from articulate/terraform-provider-okta#182.

Support amending system resources

@quantumew commented on Sep 29, 2019, 9:24 PM UTC:

Several resources don't support amending system "default" resources that get added to the tenant by default. We should either add a new resource or support it in the existing resource. The approach may vary depending on the API restrictions. More specific reports of this issue: #289 #288

• okta_auth_server
• okta_auth_server_claim
• okta_auth_server_scope
• okta_auth_server_policy
• okta_policy_password
• okta_policy_signon
• okta_policy_mfa

This issue was moved by noinarisak from articulate/terraform-provider-okta#290.

To be able to create users from a file in bulk

@msmrnv1 commented on Aug 6, 2019, 3:46 PM UTC:

I would like to be able to have an option to create users in bulk (e.g. define a list of users in JSON object) and assign them to a specific user group. I did not find any good way to do that using the current resources.
Do you have any recommendation based on the current functionality or that will be a new feature?

This issue was moved by noinarisak from articulate/terraform-provider-okta#231.

Update User Schema Resources and add User Type

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

It looks like the User Schema resources as defined here have fallen behind how they're currently implemented. Namely Schemas correspond to a User Type (which also doesn't appear to be supported.

New or Affected Resource(s)

• okta_app_user_base_schema
• okta_app_user_schema
• okta_user_base_schema
• okta_user_schema
• okta_user_type (new)

Potential Terraform Configuration

resource "okta_user_type" "contractor" {
  description    = "Third Party Contractor"
  displayName    = "Contractor"
  # Should name be pulled implictly?
  # name         = "contractor"
}

References

• https://developer.okta.com/docs/reference/api/user-types/
• https://developer.okta.com/docs/reference/api/schemas/

Better Tests

@quantumew commented on May 21, 2019, 7:45 PM UTC:

Some resources have multiple endpoints associated with them. In our tests we should check everything to validate downstream. For instance, users with group memberships. Otherwise stuff will break and we won't know. #174

This issue was moved by noinarisak from articulate/terraform-provider-okta#175.

SAML app Requestable SSO URLs

@c-knowles commented on Jul 31, 2019, 11:40 AM UTC:

Is it currently possible to set Requestable SSO URLs for SAML app configs? This option is available once Allow this app to request other SSO URLs is checked on on the SAML app setup page. I could not see an Okta API option so not sure it's even possible.

This issue was moved by noinarisak from articulate/terraform-provider-okta#227.

Directory Integrations | New resources

@robwaldron-flg commented on Apr 29, 2019, 3:06 AM UTC:

I'm pretty sure that from what I've seen, there's no API for creating directory integrations, but thought I'd add this here as a feature request.

Proposed resources:

• resource_directory_ad
• resource_directory_ldap
• resource_directory_csv

This issue was moved by noinarisak from articulate/terraform-provider-okta#151.

supporting format character restriction in Profile Editor

@msmrnv1 commented on Oct 2, 2019, 8:00 PM UTC:

I cant find a way to specify the pattern for format character restriction when I update a field in Okta schema. I tried to use something like this

resource "okta_user_schema" "schema_login" {
index = "login"
title = "Username"
type = "string"
required = true
min_length = 1
max_length = 50
pattern = "[^a-zA-Z0-9\\\\\+\@\.\_-]]+"
permissions = "READ_ONLY"
master = "PROFILE_MASTER"
validationType = "HARD"
}

This issue was moved by noinarisak from articulate/terraform-provider-okta#294.

Support for "logo" when building applications

@paullschock commented on Jul 23, 2019, 10:07 PM UTC:

When building applications via terraform, it'd be nice to be able to personalize the application by uploading a custom logo.

From reviewing the API documentation for Okta (https://developer.okta.com/docs/reference/api/apps/#add-application) this does not yet appear to be supported, but I wanted to open an issue to track in case this changes.

Possible implementation (pending implementation of the endpoint by Okta and valid input values) might be to use existing file resources to pass in a base64 version of the file.

This issue was moved by noinarisak from articulate/terraform-provider-okta#219.

app_settings_json isn't

@shawnferry commented on May 2, 2019, 9:25 PM UTC:

struct ApplicationSettings has members App and Notification.

I'm too new at this to understand how the code is working parsing the payload seems to make sense but I don't understand enough of the basic language primitives or terraform's implementation to understand why notifications appears to be silently dropped and other keys (signOn) appear to be consumed.

I agree that the range is wide and also it looks to have custom implementation possibilities. It seems like this could be

"settings_json": { <N consumed keys>, "app": ..., "notifications": ..., ...}

or

app_settings_json:
notification_settings_json:

but it isn't clear that this list wouldn't grow.

From the REST API ({{url}}/api/v1/apps) maybe the Go SDK is returning things notably differently, which would obviate a lot of this.

"settings": {
            "app": {
                "subdomain": "terraform-test"
            },
            "notifications": {
                "vpn": {
                    "network": {
                        "connection": "ZONE",
                        "exclude": [
                            "ALL_ZONES"
                        ]
                    },
                    "message": "What does this look like in the config?",
                    "helpUrl": null
                }
            },
            "signOn": {
                "defaultRelayState": null,
                "ssoAcsUrlOverride": null,
                "audienceOverride": null,
                "recipientOverride": null,
                "destinationOverride": null
            }
        },

This issue was moved by noinarisak from articulate/terraform-provider-okta#156.

Password policy - allow setting userLockoutNotificationChannels

@jeremie0 commented on Nov 12, 2019, 4:11 PM UTC:

Is your feature request related to a problem? Please describe.
The Okta UI allows us to enable "Send lockout email to user".
In the API for password policies, it looks like this is undocumented, but is set via:

"settings": {
   "password": {
      "lockout": {
          "userLockoutNotificationChannels": [
               "EMAIL"
           ]

can the terraform provider also let us set this?

Describe the solution you'd like
option for okta_policy_password to send_lockout_email = true

This issue was moved by noinarisak from articulate/terraform-provider-okta#328.

Support for setting "Application notes for admins" in apps

@bodgit commented on Apr 24, 2019, 9:34 AM UTC:

Our Okta account now has apps that are both manually set up and managed by Terraform, it will be a long time I suspect before everything in there is 100% managed by Terraform.

I figured it might be a good idea to utilize the "Application notes for admins" field in an app to add a "Managed by Terraform" hint so people know that if they manually edit the settings that they will be reverted by a future Terraform run:

This field doesn't seem to be currently managed by Terraform, would it be hard to add support to be able to manage it? (and probably the "Application notes for end users" field above it)

This issue was moved by noinarisak from articulate/terraform-provider-okta#143.

Terraform Module should pull in nested resource

@NeenuAVarghese commented on Sep 27, 2019, 9:41 PM UTC:

Actual Behavior

Cannot update sub claim in a resource in the Okta Auth server

Steps to reproduce

Links to the relevant code, snippets

resource "okta_auth_server" "custom_auth_server" {
  audiences   = "https://example.com"
  name        = "AuthServer"
}
resource "okta_auth_server_claim" "sub_claim" {
  name           = "sub"
  status         = "ACTIVE"
  claim_type     = "RESOURCE"
  value_type     = "EXPRESSION"
  value          = "some-regex"
  auth_server_id = "${okta_auth_server.custom_auth_server.id}"
}

Apply the above changes and terraform will error out saying that the claim names conflict

Expected Behavior

Terraform should be able to pull in nested resource of the auth server it creates in Okta
Note: This also causes issues when doing a terraform destroy as sub_claim is technically a system resource. In such cases, terraform provider should just destroy the auth server

This issue was moved by noinarisak from articulate/terraform-provider-okta#288.

Update App Examples

@quantumew commented on Sep 3, 2019, 12:16 AM UTC:

Now that we have the okta_app_user resource, use that in our application examples. See #248, opened this in response to confusion in #244.

This issue was moved by noinarisak from articulate/terraform-provider-okta#266.

Is it possible to set Single Logout URL?

@mcdir commented on Jul 1, 2019, 9:27 AM UTC:

Is your feature request related to a problem? Please describe.
Setup Single Logout URL via terraform-provider-okta

Describe the solution you'd like
Just any kind possibility to setup "Single Logout URL" the same as manual way in the "Edit SAML Integration>Show Advanced Settings"
Enable Single Logout > On,
Single Logout URL
SP Issuer

Describe alternatives you've considered
Didn't find

Additional context

This issue was moved by noinarisak from articulate/terraform-provider-okta#200.

Okta attempting to add user to group before user creation finishes

@hgibsonqb commented on May 7, 2019, 11:35 AM UTC:

Hi,
I'm using this provider to create two okta users, two okta groups each with a group rule, and add the two okta users to both groups.

What seems to be happening is okta attempts to create the group before the users finish creating. This is a sample run:

   module.bootstrap_sandbox_team.module.okta-membership.okta_group.group: Creating...
         description: "" => "979e15e3d929c191dd54d6820e479c8f-sandbox-desc"
         name:        "" => "979e15e3d929c191dd54d6820e479c8f-sandbox"
       module.bootstrap_team.module.okta-membership.okta_group.group: Creating...
         description: "" => "979e15e3d929c191dd54d6820e479c8f-desc"
         name:        "" => "979e15e3d929c191dd54d6820e479c8f"
       okta_user.testing2: Creating...
         email:      "" => "[email protected]"
         first_name: "" => "Test"
         last_name:  "" => "User 2"
         login:      "" => "[email protected]"
         status:     "" => "ACTIVE"
       okta_user.testing1: Creating...
         email:      "" => "[email protected]"
         first_name: "" => "Test"
         last_name:  "" => "User 1"
         login:      "" => "[email protected]"
         status:     "" => "ACTIVE"
       module.bootstrap_sandbox_team.module.okta-membership.okta_group.group: Creation complete after 1s (ID: 00gjxhnseAfQmKqpY356)
       module.bootstrap_team.module.okta-membership.okta_group.group: Creation complete after 1s (ID: 00gjxqzt1lAJ1I4cv356)

The users don't finish creating until much later

okta_user.testing2: Creation complete after 9s (ID: 00ujxq2rrPzRFvxFo356)
okta_user.testing1: Creation complete after 9s (ID: 00ujxm07rqLKsdvkp356)

This causes terraform apply to fail with the following error:

* module.bootstrap_team.module.okta-membership.okta_group_rule.group: 1 error(s) occurred:
* okta_users.testing1: unexpected EOF
* okta_group_rule.group: The API returned an error: Internal Server Error

However sometimes I'm able to apply successfully, when users finish creating before the other resources.

This issue was moved by noinarisak from articulate/terraform-provider-okta#162.

Policy and rule model seems wrong

@shawnferry commented on May 8, 2019, 8:58 PM UTC:

Looking at the existing policy and policy rules constructs I think there are type specific details vs the higher level abstractions and this also needs a refactor.

I think policy.go has members groups_[included|excluded] incorrectly it should instead have members conditions and settings as a policy object.

Then policy_rules.go would have the definition for the rules object

Both policy and policy rule would consume conditions objects...

This issue was moved by noinarisak from articulate/terraform-provider-okta#165.

new resource | ability to add administrators

@robwaldron-flg commented on Apr 23, 2019, 6:23 AM UTC:

The ability to add administrators in Okta through the user and group methods would be quite helpful (probably more so assigning groups to admin roles).

resource_roles and be able to add one or many users or groups.

https://developer.okta.com/docs/api/resources/roles/#list-roles-assigned-to-user

This issue was moved by noinarisak from articulate/terraform-provider-okta#141.

To be able to create tokens under security->API

@msmrnv1 commented on Aug 12, 2019, 6:02 PM UTC:

I would like to be able to create a token that can be used later by an application to call Okta admin APIs. Is there a way to do it today?

End Point: api/internal/tokens?expand=user
Request Param: {"name":"Test Token"}

This issue was moved by noinarisak from articulate/terraform-provider-okta#240.

Administrator Roles: add support for role targets

@bellaweo commented on Apr 24, 2018, 5:41 AM UTC:

https://developer.okta.com/docs/api/resources/roles

App Roles

This issue was moved by noinarisak from articulate/terraform-provider-okta#15.

new resource | app_push_group ?

@robwaldron-flg commented on Apr 23, 2019, 5:37 AM UTC:

Not sure if a new resource or to be embedded into an existing resource makes more sense, but using the Okta Org2Org as an example; Push Groups enables pushing users from a group in a master Okta org to be pushed into a specified group (or created on demand) in another Okta org.

In this documentation, it exists here: https://saml-doc.okta.com/Provisioning_Docs/Okta-Org2Org_Provisioning.html, but as Push Groups is a feature beyond Org2Org and can be other apps that support Push Groups (e.g. O365), it could be enabled as a standalone resource that can be used where required.

This issue was moved by noinarisak from articulate/terraform-provider-okta#139.

Internal Okta API Resources

@quantumew commented on Aug 7, 2019, 7:37 PM UTC:

Can we start to build resources for things that have no public API? In my opinion, we can as long as it we very clearly mark these resources as "contractless" and output a warning message. We should make it clear that Okta reserves the right to change the API without a version increment being that it is leveraging a /internal endpoint.

The other caveat is auth. Some of these endpoints do not take API tokens. We will potentially have to work around this.

This issue was moved by noinarisak from articulate/terraform-provider-okta#235.

New Resource: App Sign On Policy

@msmrnv1 commented on Oct 22, 2019, 6:46 PM UTC:

I can't find a resource to specify the signon policy for the app. Is there such a resource?

This issue was moved by noinarisak from articulate/terraform-provider-okta#309.

SDK

@quantumew commented on Sep 30, 2019, 1:43 PM UTC:

There are 3 SDKs technically used. The old one should go away, and mostly has. The official one is an alias for our fork due to the original being behind for sometime. The internal one because Okta doesn't support all of their endpoints. Here is the consolidation plan. Only use the official one, which is aliased to our Fork. We will move the internal endpoints to the fork, they already use the internals of the official SDK so that should be an easy move.

The old one - "github.com/articulate/oktasdk-go/okta”
The official one - "github.com/okta/okta-sdk-golang/okta"
The internal one - “github.com/articulate/terraform-provider-okta/sdk”

This issue was moved by noinarisak from articulate/terraform-provider-okta#291.