Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

supported_identity_providers in aws_cognito_user_pool_client Ordering Causing Differences #4806

Closed
esteban-angee opened this issue Jun 11, 2018 · 7 comments · Fixed by #12388
Labels
bug Addresses a defect in current functionality.
Milestone

Comments

@esteban-angee
Copy link

esteban-angee commented Jun 11, 2018

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.

@esteban-angee esteban-angee changed the title Adding supported_identity_providers in aws_cognito_user_pool_client afects AllowedOAuthScopes and CallbacURLs of the AppClient Adding supported_identity_providers in aws_cognito_user_pool_client afects AllowedOAuthScopes and CallbacURLs of the AppClient. It flips between executions Jun 11, 2018
@radeksimko radeksimko added bug Addresses a defect in current functionality. service/cognito labels Jun 13, 2018
@mmritesh
Copy link

mmritesh commented Jul 17, 2018

I am also facing the similar issue.

@maanenh
Copy link

maanenh commented Jul 24, 2018

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
Copy link

@radeksimko Any update on the progress to solve this?

@bflad
Copy link
Contributor

bflad commented Aug 9, 2018

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 bflad changed the title Adding supported_identity_providers in aws_cognito_user_pool_client afects AllowedOAuthScopes and CallbacURLs of the AppClient. It flips between executions supported_identity_providers in aws_cognito_user_pool_client Ordering Causing Differences Aug 9, 2018
@bflad bflad added this to the v2.54.0 milestone Mar 17, 2020
@bflad
Copy link
Contributor

bflad commented Mar 17, 2020

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
Copy link

ghost commented Mar 19, 2020

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
Copy link

ghost commented Apr 16, 2020

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!

@ghost ghost locked and limited conversation to collaborators Apr 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality.
Projects
None yet
5 participants