> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fastfoundation.nimble.la/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview & Prerequisites

> Learn the basics of users and access groups in AWS IAM Identity Center (formerly AWS SSO) and integrated services

# Prerequisites

Before managing users and groups, make sure of properly [setting up user management profile](/aws-sso/3-set-up-aws-sso-locally#special-case%3A-user-management-profile).

<Steps>
  <Step title="Install Required Software">
    Described in [Getting Started](/iac-management/2-getting-started) section.
  </Step>

  <Step title="Set up AWS SSO locally ">
    As described in [Set up AWS SSO locally](/aws-sso/3-set-up-aws-sso-locally)
  </Step>

  <Step title="Clone and Access the Repository">
    Clone your organization's Infrastructure as Code (IaC) repository:

    ```bash theme={null}
    git clone <iac-repository-url>
    ```

    Navigate to the user management directory:

    ```bash theme={null}
    cd Infrastructure/infrastructure/<aws-region>/permissions/sso/main
    ```

    Initialize the module:

    ```bash theme={null}
    terragrunt init
    ```
  </Step>
</Steps>

***

## Core Concepts

### Users

Users represent individuals who need access to AWS resources and applications. Each user:

* **Requires MFA (Multi-Factor Authentication)** – Enforced on the first login for security
* **Has unique credentials** – Separate from traditional AWS IAM (Identity and Access Management) users
* **Belongs to groups** – Access is granted and managed through group membership
* **Can access multiple accounts** – Single sign-on across all assigned AWS accounts

### Permission Sets

Permission sets are **reusable policy definitions** that specify what permissions a user gets. They are defined once and can be referenced by any number of groups:

* **AWS Managed Policies** – Pre-built policies maintained by AWS (e.g., `AdministratorAccess`)
* **Inline Policies** – Custom policies with granular permissions
* **Session Duration** – How long temporary access tokens remain valid

### Access Groups

Access groups define *who can access what*. Each group declares a list of **assignments** that map a permission set to a list of accounts. This N:M model means:

* **One group can have different permission sets on different accounts** (e.g., `PowerUser` on dev, `ReadOnly` on prod)
* **One permission set can be reused by many groups**
* **Applications** – Integrated applications can be attached manually

***

### Policy Types

Access groups rely on policies to define permissions. Here are the main types:

<AccordionGroup>
  <Accordion title="AWS Managed Policies">
    Pre-built policies maintained by AWS. Common examples:

    * `AdministratorAccess` – Full administrative permissions
    * `PowerUserAccess` – All permissions except IAM and billing
    * `ReadOnlyAccess` – View-only permissions across services
    * `ViewOnlyAccess` – Basic read permissions
  </Accordion>

  <Accordion title="Inline Policies">
    Custom policies created and managed within your access group:

    * Defined inside the access group itself
    * Applied automatically to all accounts assigned to the group
    * Useful for granular permissions
  </Accordion>

  <Accordion title="Customer Managed Policies">
    They must already exist in target accounts:

    * Not managed directly by the access group
    * Must be created in each target account before being referenced
  </Accordion>
</AccordionGroup>

***

## Understanding the Users\&Groups Parameter

<Warning>
  Always test changes in a development environment before applying to production accounts.
</Warning>

<Note>
  **Important**: User management changes affect access across your entire AWS organization. Always coordinate with your team and follow your organization's change management process.
</Note>

Users and groups configurations are managed through **Terragrunt** parameters, in an `inputs.hcl` file. The configuration has three main sections:

```hcl theme={null}
locals {
  # 1. Permission sets — reusable policy definitions
  permission_sets = {
    "PowerUser" = {
      description          = "Power user access"
      session_duration     = "PT8H"
      aws_managed_policies = ["arn:aws:iam::aws:policy/PowerUserAccess"]
    }
    "ReadOnly" = {
      description          = "Read-only access"
      session_duration     = "PT4H"
      aws_managed_policies = ["arn:aws:iam::aws:policy/ReadOnlyAccess"]
    }
  }

  # 2. Access groups — map permission sets to accounts
  access_groups = {
    "DevelopmentTeam" = {
      description = "Access for development team members"
      assignments = [
        {
          permission_set = "PowerUser"
          accounts       = ["workload-development", "workload-staging"]
        },
        {
          permission_set = "ReadOnly"
          accounts       = ["workload-production"]
        }
      ]
    }
  }

  # 3. Users — reference groups by name
  users = [
    {
      display_name = "John Doe"
      email        = "john.doe@company.com"
      given_name   = "John"
      family_name  = "Doe"
      groups       = ["DevelopmentTeam"]
    }
  ]
}
```