# SEC02-BP06 Employ user groups and attributes
SEC02-BP06 Employ user groups and attributes

 Defining permissions according to user groups and attributes helps reduce the number and complexity of policies, making it simpler to achieve the principle of least privilege.  You can use user groups to manage the permissions for many people in one place based on the function they perform in your organization.  Attributes, such as department or location, can provide an additional layer of permission scope when people perform a similar function but for different subsets of resources. 

 **Desired outcome:** You can apply changes in permissions based on function to all users who perform that function.  Group membership and attributes govern user permissions, reducing the need to manage permissions at the individual user level.  The groups and attributes you define in your identity provider (IdP) are propagated automatically to your AWS environments. 

 **Common anti-patterns:** 
+  Managing permissions for individual users and duplicating across many users. 
+  Defining groups at too high a level, granting overly-broad permissions. 
+  Defining groups at too granular a level, creating duplication and confusion about membership. 
+  Using groups with duplicate permissions across subsets of resources when attributes can be used instead. 
+  Not managing groups, attributes, and memberships through a standardized identity provider integrated with your AWS environments. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
Implementation guidance

 AWS permissions are defined in documents called *policies* that are associated to a principal, such as a user, group, role, or resource.  For your workforce, this allows you to define groups based on the function your users perform for your organization, rather than based on the resources being accessed. For example, a `WebAppDeveloper` group may have a policy attached for configuring a service such as Amazon CloudFront within a development account. An `AutomationDeveloper` group may have some CloudFront permissions in common with the `WebAppDeveloper` group. These permissions can be captured in a separate policy and associated to both groups, rather than having users from both functions belong to a `CloudFrontAccess` group. 

 In addition to groups, you can use *attributes* to further scope access. For example, you may have a `Project` attribute for users in your `WebAppDeveloper` group to scope access to resources specific to their project.  Using this technique removes the need to have different groups for application developers working on different projects if their permissions are otherwise the same.  The way you refer to attributes in permission policies is based on their source, whether they are defined as part of your federation protocol (such as SAML, OIDC, or SCIM), as custom SAML assertions, or set within IAM Identity Center. 

### Implementation steps
Implementation steps

1.  Establish where you will define groups and attributes. 

   1.  Following the guidance in [SEC02-BP04 Rely on a centralized identity provider](sec_identities_identity_provider.md), you can determine whether you need to define groups and attributes within your identity provider, within IAM Identity Center, or using IAM user groups in a specific account. 

1.  Define groups. 

   1.  Determine your groups based on function and scope of access required.   

   1.  If defining within IAM Identity Center, create groups and associate the desired level of access using permission sets. 

   1.  If defining within an external identity provider, determine if the provider supports the SCIM protocol and consider enabling automatic provisioning within IAM Identity Center.  This capability synchronizes the creation, membership, and deletion of groups between your provider and IAM Identity Center. 

1.  Define attributes. 

   1.  If using an external identity provider, both the SCIM and SAML 2.0 protocols provide certain attributes by default.  Additional attributes can be defined and passed using SAML assertions using the `https://aws.amazon.com/SAML/Attributes/PrincipalTag`  attribute name. 

   1.  If defining within IAM Identity Center, enable the *attribute-based access control* (ABAC) feature and define attributes as desired. 

1.  Scope permissions based on groups and attributes. 

   1.  Consider including conditions in your permission policies that compare the attributes of your principal with the attributes of the resources being accessed.  For example, you can define a condition to allow access to a resource only if the value of a `PrincipalTag` condition key matches the value of a `ResourceTag` key of the same name. 

## Resources
Resources

 **Related best practices:** 
+  [SEC02-BP04 Rely on a centralized identity provider](sec_identities_identity_provider.md) 
+  [SEC03-BP02 Grant least privilege access](sec_permissions_least_privileges.md) 
+  [COST02-BP04 Implement groups and roles](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html) 

 **Related documents:** 
+  [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [Manage Identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) 
+  [What Is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [ABAC In IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) 

 **Related videos:** 
+  [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)