Custom SAML App gets SCIM tab wiped out on re-apply on 3.13.10

[Mrorya]

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 version 0.13.5 provider version 3.13.10

Affected Resource(s)

• okta_app_saml

Terraform Configuration Files

resource "okta_app_saml" "loom" {
  label                    = "Loom SAML"
  status                   = "ACTIVE"
  sso_url                  = "https://login.loom.com/login/callback"
  recipient                = "https://login.loom.com/login/callback"
  destination              = "https://login.loom.com/login/callback"
  audience                 = "redacted"
  subject_name_id_template = "$${user.userName}"
  subject_name_id_format   = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  response_signed          = true
  assertion_signed         = true
  signature_algorithm      = "RSA_SHA256"
  digest_algorithm         = "SHA256"
  honor_force_authn        = true
  hide_ios                 = true
  hide_web                 = true
  authn_context_class_ref  = "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"

  attribute_statements {
    type      = "EXPRESSION"
    name      = "email"
    namespace = "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
    values    = ["user.login"]
  }

  attribute_statements {
    type      = "EXPRESSION"
    name      = "firstName"
    namespace = "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
    values    = ["user.firstName"]
  }

  attribute_statements {
    type      = "EXPRESSION"
    name      = "lastName"
    namespace = "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
    values    = ["user.lastName"]
  }

  skip_users  = true
  skip_groups = false

  lifecycle { ignore_changes = [groups] }
}

Expected Behavior

No change to provisioning tab on custom SAML app for new apply

Actual Behavior

We added skip_users and skip_groups to the TF for this custom SAML app which had provisioning features enabled manually via UI (the provider docs note these are not configurable via API yet) - on apply, the provisioning radio button got reset from SCIM to None and it wiped out the configuration on the provisioning that we had setup manually.

Steps to Reproduce

Configure custom SAML app via TF Configure provisioning options via Okta UI Make a change to custom SAML app via TF Apply TF plan - TF apply will wipe out provisioning settings and reset the "Provisioning" option on the custom saml app to None

Note - We had originally seen this happen on 3.13.7 - we upgraded providers recently for another issue (to get the skip_users/groups attributes) and saw this pop up again. Let us know if we're missing something as far as what we should be setting on custom SAML apps with custom SCIM integrations!

[bogdanprodan-okta]

Hi @Mrorya! Thanks for submitting this issue! I'll investigate the problem and try to fix it asap.

[masipah]

Wondering if there are any workarounds for this or if you were able to reproduce it

[bogdanprodan-okta]

@Mrorya I think this might be related to the #710 issue.

[Mrorya]

@bogdanprodan-okta - Thanks! I'll keep an eye out for the next version release and we'll test on our side that it resolves the provisioning tab issue.

[bogdanprodan-okta]

Hi, @Mrorya! Does the issue regarding features still exist?

[bogdanprodan-okta]

Closing this for now. Please create another issue or leave a comment here in case the problem still exists.

[JasonBuckner]

I can confirm that this issue is still occurring on version 3.22.

[nickrmc83]

Can confirm we're also hitting this.

[monde]

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

[shortcut-opsadmin]

Hi @monde - Question- Setting the features to computed still doesn't prevent this issue.

For example:

• SAML app with SCIM enabled manually
• Run a terraform for a small change in okta_app_saml and the resulting app loses the Provisioning: SCIM that was once set on it. (Regardless of features being hinted previously or not at all )

If I make the same small change via the UI, it does not wipe out the Provisioning: SCIM.

Currently: This is a MAJOR bug for us as it wipes out credentials that were set one-time manually out of band and can break full app specifications.

I'd thus still consider this a bug?

[Mrorya]

We've noticed the same thing - all custom saml apps are still getting their provisioning configurations removed if there's a modification to the app (example: changing the authentication policy)

[monde]

@shortcut-opsadmin are you on a classic org? @Mrorya remind me, I think you are on a classic org?

I'm working on some bug fixes right now will pad in some extra tests on okta_app_saml and see if I can address it.

[Mrorya]

We are on OIE

[virgofx]

@shortcut-opsadmin are you on a classic org?

Shoot, wrong user @monde .. Tis is me. Service account was elevated in tab 😢

We're OIE I can do a quick screen demo if you want to see the issue if that helps?

[virgofx]

1. Create the terraform app below via terraform apply
2. Update the General tab (not supported via API but would be awesome if Okta supported this 😢 ) to Provisioning: SCIM.
3. This enables the Provisioning tab (for the sake of testing, no need to add details here as this does require actual valid creds); however, do note that when the following bug via TF API occurs below, it does wipe all Provisioning/Integration fields.
4. Via the UI, note you can change the end_user_note in the General tab and the Provisioning correctly field remains on [SCIM].
5. Attempt to do the same thing via Terraform. Update enduser_note to anything to force a new change.
6. Observe that in the UI, the Provisioning field has been removed from SCIM back to NONE, thereby wiping out the previously entered settings in the Provisioning/SCIM settings :(

resource "okta_app_saml" "tester123" {
  label = "tester123"

  sso_url                  = "https://auth.workos.com/sso/saml/acs/xxxxxxxxxxxxxx"
  recipient                = "https://auth.workos.com/sso/saml/acs/xxxxxxxxxxxxxx"
  destination              = "https://auth.workos.com/sso/saml/acs/xxxxxxxxxxxxxx"
  audience                 = "https://auth.xxxxxxxxxxxx.com/xxxxxxxxxx"
  saml_version             = "2.0"
  subject_name_id_format   = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  subject_name_id_template = "$${user.userName}"
  signature_algorithm      = "RSA_SHA256"
  digest_algorithm         = "SHA256"
  authn_context_class_ref  = "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
  response_signed          = true
  assertion_signed         = true

  # Use this to test
  # enduser_note = "asdfsdfsdfsfsfsdfsdfssdfsdf3"
}

[monde]

This is what I'm working on now. Wanted to get this into v3.37.0 but prepping that release took longer than I planned.

[monde]

@virgofx I'm not able to reproduce this bug. But I'm using a new org that is running off the pre-production Okta build, which might mean this behavior no longer exists. I sent you an zoom invite to look at it again. I do see a public endpoint that the Admin UI is using /api/v1/apps/{appId}/scim-connector but that isn't documented in the Public API https://developer.okta.com/docs/reference/api/apps/ Perhaps if we can make use of it, I'll negotiate internally to get it to be blessed as fully public.

[virgofx]

Sounds good, Monday works and will look at it again to see if I can pull some more details ahead of time

[virgofx]

Testing Update

It appeared that this problem was consistently observed > 3 days ago during API calls/Terraform. However, today, 10/10/22, it now appears to be working when testing on 2 different tenants. Specifically, the SCIM provisioning is not getting dropped. Perhaps that may have be an internal logic fix for the update/PATCH endpoints?

[monde]

Notes from debugging w/ Mark: App: General > Provisioning > SCIM Provisioning > Integration > SCIM Connection > OAuth2 I couldn't reproduce with an OAuth2 connector. But the bug was reported while using an HTTP Header bearer token. I need to try and reproduce with a HTTP Header.

[monde]

Okta Internal Reference: https://oktainc.atlassian.net/browse/OKTA-539875

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days