Enable okta_password authenticator for okta_policy_mfa

[nickrmc83]

Enable synchronising and setting okta_password authenticator configuration on okta_policy_mfa resources. See previous issue comment for more context. I've not had a chance to extensively test this fix yet and so should be treated as speculative at this point.

It should allow for policies such as the below to work with OIE without encountering a At least one of Password or Email authenticator must be set to required error:

resource "okta_policy_mfa" "example_policy" {
  name  = "An example policy"
  status = "ACTIVE"
  description = "MFA policy as an example"
  priority = 1
  is_oie  = true

  okta_password = {
    enroll = "REQUIRED"
  }
  
  okta_email = {
    enroll = "NOT_ALLOWED"
  }

  fido_webauthn = {
    enroll = "REQUIRED"
  }
 }

[virgofx]

@nickrmc83 Are you testing in an OIE environment? I believe the changes above will break and not-work in an OIE tenant. Enabling password breaks sync as okta_password isn't returned by the API as noted in the comments. I'll try to take a look to see if I can confirm

[monde]

Thanks for the PR @nickrmc83 I'll have to look into this later this week. Thanks the extra experience @virgofx - I will definitely first see if the ITs for okta_policy_mfa fail on my various test orgs (classic, oie, etc.)

[nickrmc83]

Are you testing in an OIE environment

Yes we are. I'm trying to enable okta_verify to use with Fastpass whilst also requiring users to register a password. I've played around in the web console and used Chrome's web dev tools to observe the API activity. I can see the setting for okta_password being sent and the API suggests it should be possible to specify this authenticator. I've not finished testing this PR because I was having problems convincing terraform to use my locally built provider.

[monde]

@nickrmc83 if you rebase master you'll get this commit 4071493 . It adds a feature where the provider discovers if it is running against an OIE or classic org and saves that as a boolean on the provider config classicOrg bool

func example(ctx context.Context, m interface{}) error {
	// `m` is the provider config struct

	// Inspecting the ACCESS_POLICY is OIE only https://developer.okta.com/docs/reference/api/policy/#policy-object
	// "Note: The following policy types are available only with the Identity Engine: ACCESS_POLICY or PROFILE_ENROLLMENT."

	// An example of making use of this info: If the org is not OIE return early
	if config, ok := m.(*Config); ok && config.classicOrg {
		return nil
	}

	// do something
	return nil
}

[nickrmc83]

@monde I've merged the latest head into my remote branch 👍

[edlott]

I need this as well. I work in an 'is_oie = 1' tenant and this change will work for me. A recap of this commit:

• If 'okta_password' stanza is present, it will generate 'settings' changes in the payload. I verified that the Okta admin console does in fact send this stuff, so this isn't a problem.

[nickrmc83]

@monde is there likely to be any movement on this issue?

[monde]

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

[monde]

@nickrmc83 I want to spend some time looking into this further given the classic/oie impact and have triaged it into our internal backlog.

[edlott]

"I want to spend some time looking into this further given the classic/oie impact and have triaged it into our internal backlog"

Your original work (prior to this PR) was very intentional about not allowing this. I'm not sure what inspired you to block this functionality (perhaps out-of-date docs, or other information that's no longer relevant).

The Okta admin console clearly functions the same as this PR. Please let me know if any of the following would make you feel better about the PR:

• Screen-shots of the REST calls made by the admin UI that illustrates functionality of the PR.
• Postman test making calls like the PR.

The Okta platform is in a state of flux. I'm hoping you're not over-thinking this, or trying to divine the platform's long-term intentions. It's better to be nimble and exact at this point.

I'm using a custom build with this PR as we speak. I need to share share my terraform scripts with others, so they have to use my custom build as well. It would be much easier if this PR could be part of your release, so I don't have to manually distribute the provider.

Would it be possible to integrate this PR but have a command-line flag to turn the controversial functionality on/off?

[nickrmc83]

@monde is there any more we can do to move this forward? We'd like to get back to using a mainline release.

[monde]

I'll try to dedicate time to look at this in my current sprint.

[nickrmc83]

@monde sorry to push but the lack of support for configuring password + Okta Verify using an official release is now causing us challenges. Do you have a timeline when this will be possible?

[Matt-Hodgs0n]

Hi - commenting to add to the general feedback on this issue. We are unable to use Terraform to create/configure MFA enrollment policies in OIE without receiving this error and have tried many workarounds, combinations to try resolve without success. We've had to go back to manually configuring MFA enrolment policies until a fix is available.

[monde]

I'll be bringing @nickrmc83's work in under PR #1427

[monde]

Forgot to shout this was released in https://github.com/okta/terraform-provider-okta/releases/tag/v3.41.0