supported_identity_providers in aws_cognito_user_pool_client Ordering Causing Differences

[esteban-angee]

Terraform Version

Terraform v0.11.7
+ provider.archive v1.0.0
+ provider.aws v1.22.0

Affected Resource(s)

• aws_cognito_user_pool_client

Terraform Configuration Files

resource "aws_cognito_user_pool" "kaizen_user_pool" {
  name                = "${var.project}-user-pool-${var.environment}"
  username_attributes = ["email"]

  schema {
    attribute_data_type = "String"
    name                = "email"
    required            = true

    # These are de defaults. If not specified, terraform would create/destroy this resource on 
    # every plan.
    string_attribute_constraints {
      min_length = 0
      max_length = 2048
    }
  }

  schema {
    attribute_data_type = "String"
    name                = "family_name"
    required            = true

    # These are de defaults. If not specified, terraform would create/destroy this resource on 
    # every plan.
    string_attribute_constraints {
      min_length = 0
      max_length = 2048
    }
  }

  schema {
    attribute_data_type = "String"
    name                = "name"
    required            = true

    # These are de defaults. If not specified, terraform would create/destroy this resource on 
    # every plan.
    string_attribute_constraints {
      min_length = 0
      max_length = 2048
    }
  }

  password_policy {
    minimum_length    = 8
    require_lowercase = true
    require_uppercase = true
    require_numbers   = true
    require_symbols   = true
  }

  admin_create_user_config {
    allow_admin_create_user_only = true
    unused_account_validity_days = 7
  }
}

resource "aws_cognito_identity_provider" "kaizen_saml" {
  user_pool_id  = "${aws_cognito_user_pool.kaizen_user_pool.id}"
  provider_name = "PeoplesTrustADFS"
  provider_type = "SAML"

  provider_details {
    MetadataURL = "<URL-here>"
  }

  attribute_mapping {
    name        = "<a-mapping>"
    family_name = "<a-mapping>"
    email       = "<a-mapping>"
  }
}

resource "aws_cognito_user_pool_client" "localhost" {
  name                   = "localhost"
  user_pool_id           = "${aws_cognito_user_pool.kaizen_user_pool.id}"
  refresh_token_validity = 30
  callback_urls          = ["https://localhost:3000/"]
  allowed_oauth_flows    = ["code", "implicit"]
  allowed_oauth_scopes   = ["phone", "email", "openid", "profile"]

  supported_identity_providers = ["${aws_cognito_identity_provider.kaizen_saml.provider_name}", "COGNITO"]
}

Expected Behavior

Calling aws cognito-idp describe-user-pool-client should return this:

{
    "UserPoolClient": {
        "CallbackURLs": [
            "https://localhost:3000/"
        ],
        "AllowedOAuthScopes": [
            "email",
            "openid",
            "phone",
            "profile"
        ],
        "UserPoolId": "us-east-2_anId",
        "AllowedOAuthFlowsUserPoolClient": false,
        "LastModifiedDate": 1528729174.422,
        "ClientId": "another-id",
        "AllowedOAuthFlows": [
            "code",
            "implicit"
        ],
        "RefreshTokenValidity": 30,
        "CreationDate": 1528724981.009,
        "ClientName": "localhost"
    }
}

Actual Behavior

Calling aws cognito-idp describe-user-pool-client returns this, which is radically different:

{
    "UserPoolClient": {
        "UserPoolId": "us-east-2_EnBIWIdbg",
        "LastModifiedDate": 1528728467.294,
        "ClientId": "ldhmir6tqma88h3i7si53cau9",
        "AllowedOAuthFlowsUserPoolClient": false,
        "SupportedIdentityProviders": [
            "COGNITO",
            "PeoplesTrustADFS"
        ],
        "RefreshTokenValidity": 30,
        "CreationDate": 1528724981.009,
        "ClientName": "localhost"
    }
}

Steps to Reproduce

1. terraform plan
2. terraform apply
3. terraform plan
4. terraform apply

EDIT:
After further research it seems like the order of elements in supported_identity_providers changes on every/plan apply and this affects some other attributes of the aws_cognito_user_poor_client resource.

Here's the terraform plan output of two successive terraform plan/terraform apply sequences without modifications to the code:

First time:

~ module.dev-cloud.module.cognito_user_pool.aws_cognito_user_pool_client.localhost
      allowed_oauth_flows.#:                  "0" => "2"
      allowed_oauth_flows.2645166319:         "" => "code"
      allowed_oauth_flows.3465961881:         "" => "implicit"
      allowed_oauth_scopes.#:                 "0" => "4"
      allowed_oauth_scopes.2517049750:        "" => "openid"
      allowed_oauth_scopes.2603607895:        "" => "phone"
      allowed_oauth_scopes.4080487570:        "" => "profile"
      allowed_oauth_scopes.881205744:         "" => "email"
      callback_urls.#:                        "0" => "1"
      callback_urls.0:                        "" => "https://localhost:3000/"
      supported_identity_providers.0:         "COGNITO" => "PeoplesTrustADFS"
      supported_identity_providers.1:         "PeoplesTrustADFS" => "COGNITO"

Second time:

 ~ module.dev-cloud.module.cognito_user_pool.aws_cognito_user_pool_client.localhost
      supported_identity_providers.0:         "COGNITO" => "PeoplesTrustADFS"
      supported_identity_providers.1:         "PeoplesTrustADFS" => "COGNITO"

EDIT #2:
Even though the second time I run terraform plan/terraform apply only shows me the change in the order of the supported_identity_provider elements:

 ~ module.dev-cloud.module.cognito_user_pool.aws_cognito_user_pool_client.localhost
      supported_identity_providers.0:         "COGNITO" => "PeoplesTrustADFS"
      supported_identity_providers.1:         "PeoplesTrustADFS" => "COGNITO"

Applying causes values of allowed_oauth_flows and allowed_oauth_scopes to be removed from the resource even though no indication of such behavior is indicated by the plan. If I run terraform plan/terraform apply again everything returns to normal.

[mmritesh]

I am also facing the similar issue.

[maanenh]

Same flip-flop here. Even with only one supported_identity_providers
Terraform v0.11.3

• provider.archive v1.0.0
• provider.aws v1.28.0

======================
More info about my issue:
In my case the cognito_user_pool was already created by Terraform earlier (and an older version of Terraform). After the initial creation the identity_provider was added.
In this use-case, every time terraform apply is executed the result is a kind of flip-flop:

• After first executen the ExplicitAuthFlows is there, but no SupportedIdentityProviders
• After the next exection the ExplicitAuthFlows is deleted and de SupportedIdentityProviders is added again

[mmritesh]

@radeksimko Any update on the progress to solve this?

[bflad]

The fix for properly passing all attributes during aws_cognito_user_pool_client updates has been merged into master and will release with version 1.32.0 of the AWS provider, likely middle of next week. This should prevent the flip-flop apply behavior of the non-supported_identity_providers attributes.

We'll need to specifically address supported_identity_providers separately as it seems like the attribute might need to be schema.TypeSet instead of schema.TypeList from the descriptions above (I have not investigated anything personally though).

[bflad]

The followup fix for ignoring supported_identity_providers ordering has been merged and will release with version 2.54.0 of the Terraform AWS Provider, later this week. Thanks to @DrFaust92 for the implementation. 👍

[ghost]

This has been released in version 2.54.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!