Groups
Collections of identities (users, devices) used to assign permissions and policies at scale.
What is Groups?
Groups are collections of identities (users, service accounts, devices) that simplify access management by allowing administrators to assign permissions to groups instead of individuals. When a user is added to a group, they inherit all permissions assigned to that group. Groups are a core component of RBAC (Role-Based Access Control) and are used in Active Directory, LDAP, and CIAM platforms. Well-designed group structures reduce administrative overhead and minimize access-related errors.
Analogy
Think of groups like a university's course registration system. Instead of assigning permissions to each student individually (Student A gets access to Math 101), you create a 'Math 101 Students' group and assign permissions once. Add/remove students from the group, and permissions update automatically.
Types and Use Cases
Group Types:
- Security Groups: Control access to resources (files, applications, APIs)
- Distribution Groups: Email distribution lists (not for access control)
- Nested Groups: Groups within groups (inheritance chain)
- Dynamic Groups: Membership based on rules (department = 'Engineering')
Common Use Cases:
- Department Groups: HR, Engineering, Sales each have different access
- Project Teams: Temporary groups for specific projects (auto-expire)
- Access Reviews: Audit group memberships for SOX compliance
- CIAM: Group customers by tier (Free, Premium, Enterprise)"
How it Works
{
"group": {
"groupId": "group_engineering",
"displayName": "Engineering Team",
"members": ["user_123", "user_456", "user_789"],
"permissions": ["read_code", "write_code", "create_pull_request"],
"nesting": ["group_all_employees"], // Inherits from parent
"dynamicRules": { "department": "Engineering" }
}
}Groups vs Individual User Permissions
Groups
Individual User Permissions
Groups assign permissions to many users at once,
individual permissions are per-user
Groups simplify scaling access management, individual permissions don't scale
Groups enable bulk updates (add user to group = add many permissions), individual requires manual updates
Best Practices for Groups
- Use Nested Groups: Create hierarchy (All Employees → Department → Team) for inheritance"
- Regular Access Reviews: Quarterly audit group memberships (SOX requirement)"
- Principle of Least Privilege: Only add users to groups they need (avoid 'All Users' group with admin access)"
How LoginRadius Powers Groups
LoginRadius CIAM platform provides enterprise-grade group management with unlimited custom groups, nested group support (up to 5 levels), dynamic membership rules (auto-assign based on user attributes), and comprehensive audit logs for all group changes. Our platform allows you to map groups to roles/permissions, manage memberships via API, and perform bulk operations for efficient access management.
FAQs
Groups are collections of users (containers), while Roles are sets of permissions (policies). A user gets permissions by being in a group that has a role. Think: Groups = 'who', Roles = 'what they can do'. Example: 'Engineering Group' has 'Developer Role' (read/write code). LoginRadius supports both groups and roles with flexible mapping.
Nested groups provide permission inheritance: Parent group permissions flow to child groups. Example: 'All Employees' group has 'read internal wiki' permission; 'Engineering' group is nested under 'All Employees' - engineers inherit wiki access. LoginRadius supports nested groups with configurable inheritance depth (max 5 levels recommended).
LoginRadius provides comprehensive group management: (1) Unlimited Custom Groups - create groups for any criteria, (2) Nested Groups - up to 5 levels of inheritance, (3) Dynamic Membership - auto-add users based on attributes (department, location), (4) API Management - create/update groups programmatically, (5) Audit Logs - track all group membership changes.