Category: Directory Services

Group

Also known as: Security Group, User Group

Simply put

In identity and access management, a group is a named collection of users (and sometimes other groups) that lets administrators manage many identities as a single unit. Instead of assigning permissions or settings to each person individually, an administrator can assign them once to the group and have every member inherit them. This makes granting and removing access easier as people join, move within, or leave an organization.

Formal definition

A group is a directory or identity-store construct that aggregates principals (typically user accounts, and in many implementations nested groups or service identities) under a single addressable object, commonly identified by a name and unique identifier. Groups are widely used as a subject-grouping mechanism to simplify access assignment: in RBAC-oriented deployments they are often mapped to or used to convey roles and entitlements, and their membership may be emitted as claims (for example in a SAML assertion or an OIDC/JWT token) for consumption by a relying party or policy decision point. The precise semantics, supported nesting, membership resolution, and whether a group grants authorization directly or only serves as an attribute for downstream policy evaluation vary by directory technology (for example LDAP-based directories) and vendor. Note that a group is a mechanism for organizing subjects and does not itself perform authentication; how group membership influences authorization depends on the enforcement model and configuration. Evidence in this packet defines 'group' only in general and mathematical senses, so IAM-specific behavioral details here reflect standard practitioner usage rather than the cited sources.

Why it matters

Groups are one of the most widely used mechanisms for making access management scalable. Assigning permissions to individual users one at a time does not scale in an organization of any meaningful size, and it produces inconsistent, error-prone access states as people are hired, transferred, and offboarded. By collecting principals under a single addressable object, a group lets an administrator assign an entitlement once and have every member inherit it, and it lets that assignment be revoked cleanly by changing membership rather than hunting through per-user grants. This directly supports joiner-mover-leaver processes and reduces the accumulation of orphaned or excessive privileges over time.

Because groups are so convenient, they are also a common source of access risk when their semantics are misunderstood. A group is a subject-grouping construct, not an authentication mechanism, and whether membership actually grants authorization depends entirely on the enforcement model and configuration downstream. In many deployments group membership is emitted as a claim in a SAML assertion or an OIDC/JWT token and then interpreted by a relying party or policy decision point, which means the same group can convey different effective access depending on how each consuming application maps it. Nested groups and inconsistent membership resolution across directory technologies can make the real reach of a group difficult to reason about, which is why access reviews and certification campaigns frequently focus on group membership and on the entitlements groups confer.

The practical consequence for governance is that groups sit at the boundary between identity administration and runtime enforcement, and treating them as if they were self-contained roles can obscure who can actually do what. Careful naming, ownership, and periodic review of group membership are typically necessary to keep the convenience of groups from turning into unaccounted-for privilege sprawl.

Who it's relevant to

IAM Engineers and System Administrators

They create and maintain groups in directories and identity stores, manage membership as part of joiner-mover-leaver processes, and configure how membership is emitted as claims to relying parties. Understanding nesting behavior and membership resolution in the specific directory technology in use is essential to predicting effective access.

Security Architects

They decide how groups map to roles, entitlements, and policy inputs across an access control model such as RBAC or ABAC, and where group membership should grant authorization directly versus only serve as an attribute for downstream policy evaluation. This shapes how consistently the same group is interpreted across applications.

Identity Governance Leads and Compliance Officers

They run access reviews and certification campaigns that frequently center on group membership and the entitlements groups confer. Because group semantics vary by deployment, they need clear ownership and naming to certify that membership reflects legitimate business need and to control privilege accumulation.

Application and Relying-Party Owners

They consume group claims delivered in SAML assertions or OIDC/JWT tokens and define how those claims translate into permissions within their application. Since the same group can produce different effective access depending on each application's mapping, they need to document and validate their own interpretation of incoming group information.

Inside Group

Group membership

The set of principals (users, service accounts, or in some directories nested groups) that belong to the group. Membership is typically the mechanism by which the group associates identities together for a shared purpose.

Group identifier and attributes

A unique identifier (such as a distinguished name in LDAP directories or an object ID) plus descriptive attributes like display name, description, and type. The exact attribute schema varies by directory and vendor.

Nested (hierarchical) groups

Groups that contain other groups as members, allowing membership to be inherited transitively. Support for nesting and how deeply it resolves depends on the directory and configuration.

Group type or scope

A classification that governs how the group is used, for example security groups intended for access decisions versus distribution or collaboration groups. Available types depend on the platform.

Assigned entitlements or role mappings

The permissions, roles, or resource assignments linked to the group so that members inherit them. In an RBAC context a group is often mapped to one or more roles; the group itself is not the same construct as a role.

Common questions

Answers to the questions practitioners most commonly ask about Group.

Is a group the same thing as a role?

No, though the two are frequently conflated. A group is typically a collection of principals (users, and in some directories other groups or service accounts) used to simplify management by treating many identities as one unit. A role, in RBAC, is an abstraction that bundles permissions and is assigned to principals. Groups often serve as a mechanism to assign roles or entitlements, but membership in a group is not itself an authorization model. Depending on the deployment, a group may map to a role, but the two concepts remain distinct: groups answer 'who belongs together,' while roles answer 'what a principal may do.'

Does adding a user to a group authenticate them or grant them access on its own?

No. Group membership is an attribute of an identity, not an authentication event and not access enforcement by itself. Authentication verifies who the principal is; authorization decisions are made separately, often by a policy decision point that may consume group membership as one input. In most deployments, a group only affects access when some downstream system or policy references that group to grant entitlements. The presence in a group does not bypass identification, authentication, or the authorization step.

How is group membership typically communicated to a relying application?

This varies by protocol and configuration. In SAML 2.0 federations, group membership is often conveyed as attribute statements in the assertion. In OpenID Connect, groups may appear as a custom claim in the ID token or be retrieved from a userinfo endpoint, depending on how the provider is configured. Directory-integrated applications may query group membership directly via LDAP. Because groups can produce large claim sets, some deployments omit them from tokens and resolve membership through a separate lookup instead.

How are groups provisioned and synchronized across systems?

SCIM provides a standard resource model that includes a Group resource, allowing an identity provider or IGA system to create groups and manage membership in downstream applications. Directory synchronization tools may replicate groups between LDAP directories or between an on-premises directory and a cloud identity service. The exact synchronization behavior, including whether membership is authoritative at the source or can be edited at the target, depends on the provisioning configuration and the connectors involved.

How should nested groups be handled in an implementation?

Support for nested groups (groups as members of other groups) varies by directory and application. Some systems resolve nesting transitively so that a principal inherits entitlements from parent groups, while others only evaluate direct membership. Deep or circular nesting can complicate membership resolution, increase evaluation cost, and make it harder to reason about effective access. Whether nesting is flattened during provisioning or resolved at query time is a deployment-specific decision that affects both performance and auditability.

How do groups relate to access reviews and segregation of duties?

In identity governance and administration, groups are commonly a unit that access certification campaigns review, since a reviewer may need to attest to who belongs to a group and what that membership grants. Because a single group can convey multiple entitlements, unclear or overly broad groups can obscure what access a review is actually approving. Segregation of duties analysis typically must resolve group memberships to the underlying entitlements to detect toxic combinations, rather than treating the group name alone as sufficient.

Common misconceptions

A group is the same thing as a role in RBAC.

A group is primarily a collection of principals, while a role in RBAC is a named set of permissions. In many deployments groups are mapped to roles or used to assign roles, but conflating the two obscures the distinction between who is grouped together and what permissions are granted. The relationship depends on how the system is modeled and configured.

Group membership authenticates a user.

Group membership is used in authorization decisions to determine what a principal may do; it plays no part in authentication, which verifies who the principal is. Identification, authentication, and authorization remain separate steps, and group evaluation occurs after a principal has been authenticated.

Managing groups is purely a runtime enforcement concern.

Group lifecycle activities such as provisioning members, conducting access reviews, and certifying membership are identity governance and administration (IGA) concerns, distinct from runtime enforcement where a policy decision point evaluates group-derived attributes. The two should not be blurred.

Best practices

Define a clear naming convention and documented purpose for each group so that membership intent and associated entitlements are unambiguous during audits.

Include groups and their memberships in periodic access reviews and certification campaigns as part of IGA, since stale membership can silently grant unintended access.

Use nested groups cautiously and document the hierarchy, because deep or circular nesting can make effective membership and resulting authorization difficult to reason about and may resolve differently depending on the directory.

Keep group-to-role or group-to-entitlement mappings explicit and reviewed, rather than assuming a group implicitly equals a role, to preserve the distinction between grouping principals and granting permissions.

Apply segregation of duties checks to group assignments so that a single principal's combined memberships do not produce conflicting or excessive privileges.

Automate group membership provisioning and deprovisioning where possible, for example via SCIM in supporting environments, and tie changes to authoritative identity lifecycle events to reduce orphaned access.