feat: Add support for externally managed SSO users (ie. SCIM)

[fcuello-fudo]

Allow defining users as "external" when they are created by an external provider like SCIM but we still want to manage groups and groups assignements here.

[fcuello-fudo]

Hi @novekm, what do you think about this one?

[novekm]

Hi @fcuello-fudo, this is the current functionality of the module.

When users are created externally (in external Identity Provider such as Okta, Azure AD, etc.), these are synced via SCIM to IAM Identity Center once configured. The aws_identitystore_user resource is only used to create users (e.g. if you want to use IAM Identity Center as the identity provider, not an external IdP). The same applies to groups that you wish to create (aws_identity_store_group). These would not be created via Terraform if you are syncing with SCIM.

The module currently supports being able to assign permissions to the users/groups that are created via Terraform (done if you are using IAM Identity Center as the IdP) as well as assigning permissions to existing users/groups that are synced from external IDP with SCIM. These are fetched via data sources.

[fcuello-fudo]

These would not be created via Terraform if you are syncing with SCIM.

When using Google Workspace, the groups are not created using SCIM but the users are, this leaves the groups managed by terraform and the users by SCIM.

At the moment I don't think it's possible to assign users created by SCIM to groups created by terraform unless we skip the creation of the users using aws_identitystore_user .

Is there any other way?

[novekm]

When using Google Workspace, the groups are not created using SCIM but the users are, this leaves the groups managed by terraform and the users by SCIM.

Ah, I forgot about that limitation Google Workspace has with SCIM. Have you looked into ssosync as a method to sync the groups as well as the users from Google Workspace?

[fcuello-fudo]

Have you looked into ssosync as a method to sync the groups as well as the users from Google Workspace?

Yes, but I'd rather keep it simple instead of adding more tools.

Another option would be to manage user assignments in the sso_groups map instead. I think defining groups and the members is more clear than defining users and their group memberships.

Another alternative would be to define a new var sso_unmanaged_users (or sso_managed_users) that includes user creation but the other one doesn't.

Or maybe just the attribute name I suggested is not clear enough and skip_user_creation is a better one.

[novekm]

I think I get what you may be looking for. For a sample tf config, are you looking for something like the following?

module "aws-iam-identity-center" {
  source = "aws-ia/iam-identity-center/aws" 

  // Create desired GROUPS in IAM Identity Center (since Google Workspace SCIM will not sync groups)
  sso_groups = {
    Admin : {
      group_name        = "Admin"
      group_description = "Admin IAM Identity Center Group"
    },
    Dev : {
      group_name        = "Dev"
      group_description = "Dev IAM Identity Center Group"
    },
    # etc.
  }

  // Reference EXISTING users to assign them to groups in IAM IdC (users synced from Google Workspace)
  google_sso_users = {
    GoogleUser1 : {
      group_membership = ["Admin", "Dev", "QA", "Audit"]
      user_name        = "google1"
      given_name       = "Google"
      family_name      = "User 1"
      email            = "nuzumaki@hiddenleaf.village"
    },
    GoogleUser2 : {
      group_membership = ["QA", "Audit"]
      user_name        = "google2"
      given_name       = "Google"
      family_name      = "User2"
      email            = "suchiha@hiddenleaf.village"
    },
    # etc.
  }

  # permission sets

  # account assignments

}

[fcuello-fudo]

I think I get what you may be looking for. For a sample tf config, are you looking for something like the following?

Yes, that would work. Another alternative would be:

module "aws-iam-identity-center" {
  source = "aws-ia/iam-identity-center/aws" 

  // Create desired GROUPS in IAM Identity Center (since Google Workspace SCIM will not sync groups)

  sso_groups = {
    Admin : {
      group_name        = "Admin"
      group_description = "Admin IAM Identity Center Group"
      group_members = [
        "user1@example.com",
        "user2@example.com",
     ]
    },
    Dev : {
      group_name        = "Dev"
      group_description = "Dev IAM Identity Center Group"
      group_members = [
        "user1@example.com",
        "user3@example.com",
     ]

    },
    # etc.
  }

  # permission sets

  # account assignments
 }

, where group_members assigns existing users (because we are using data) to the groups being created.

[fcuello-fudo]

, where group_members assigns existing users (because we are using data) to the groups being created.

@novekm what do you think about this approach? It would also be more consistent with the AWS Console view

[smellyspice]

@novekm - with regards to your ask for me to look at the comment in this PR -- I think the big miss here is that the native Terraform provider doesn't provide for a list-users operation. Being able to list all your SCIM users into a data resource would make life much easier.

I've done this using a terraform external provider that then calls the AWS CLI command. I then use a second external provider to call the AWS SCIM API GetUser operation to enrich the user data.

This is still a work in progress, but I'm hoping I can get enough enriched data from SCIM so as to place SCIM users into some default, group based, permission sets. For example, I auto-generate groups based on some Department information fetched through SCIM and then I populate my discovered users into those groups. This gives us a good starting point for basic access. I then hand create custom groups, adding discovered users (like @fcuello-fudo has in his comment) and then merge the two groups into one larger sso_groups var that I then pass to this module.

But now I see in-line policies aren't supported yet. So more modifications are needed. I've done so much hacking to this module at this point that it probably makes more sense to just merge all the work and use the native resources directly.

[novekm]

Hi @fcuello-fudo - I like the approach, my only concern is that it could lead to duplication of code when trying to add users to multiple groups (e.g. for 10 groups, user1@example.com would need to be pasted 10 times, increasing the amount of code). This could also make readability a bit hard as the number of users within each group increases. I'd also like to try to avoid making major changes to the module if at all possible.

We're currently working to review PR #20 and may add this additional Google Workspace functionality in the next release, or soon after. We'd likely want to keep the versions a bit more distinct (e.g. v0.0.3 - add inline policies, permissions boundaries, and update use of data sources and v0.0.4 - add support for managing groups only (and users from external IdP) for the Google Workspace use case.

@smellyspice yes we're aware of this unfortunate limitation of the current version of the Terraform AWS provider - you can list groups, but currently can only list individual users and must loop through to fetch all of them. I agree that a data source for this would make things a lot easier. Separately, I'm working on a PR for the AWS provider to add this support, but don't have a current timeline on when I'll have the time to finish that up. I'll continue to reply here as updates are made.

We're targeting to have #20 merged in and new release cut hopefully within the next 1-2 weeks, and a following PR adding the other support mentioned (specifically to address the nuances of Google Workspace) hopefully soon thereafter.

[fcuello-fudo]

my only concern is that it could lead to duplication of code when trying to add users to multiple group

I think it's more common to have more users than groups, in which case this approach could lead to less code.

This could also make readability a bit hard as the number of users within each group increases.

IMO it a lot more readable to have a group with a list of users than to have to check each user to find out which users belong to a group.

I'd also like to try to avoid making major changes to the module if at all possible.

That is my main concern as well, but given that we are at version 0.0.2 then I would say it's kind of expected ;)

We're targeting to have #20 merged in and new release cut hopefully within the next 1-2 weeks, and a following PR adding the other support mentioned (specifically to address the nuances of Google Workspace) hopefully soon thereafter.

Cool, thanks!

[novekm]

Hi @fcuello-fudo, this functionality has been added in v0.0.5 which was released today 🙂

[fcuello-fudo]

Hi @fcuello-fudo, this functionality has been added in v0.0.5 which was released today 🙂

Thank you! I'm already testing it :)