Roles and Permissions

A well-structured role-based access control (RBAC) system is essential for effectively managing user permissions in B2C and B2B environments. LoginRadius provides a flexible and scalable RBAC framework tailored to the needs of businesses offering services to individual customers (B2C) and organizations (B2B). This system ensures that users and organizations access only the features and data they are authorized to access, enhancing security and operational efficiency.

This guide is organized into two self-contained tracks — pick the one that matches your product:

Choosing Your Model: B2C vs B2B

	B2C Role Management	B2B Role Management (Partner IAM)
Model shape	Single-tier — roles and permissions assigned directly to consumers	Two-tier — tenant permissions and roles, plus per-organization roles
Where roles live	At the tenant/application level	Tenant roles span all organizations; organization roles are scoped to one org
Who administers	Your application/admin team	Tenant admin (permissions and tenant roles) + org admins (organization roles)
Typical scenario	Consumer apps, subscription tiers, community roles	Multi-tenant SaaS serving many business customers

If you serve individual end users, follow B2C Role Management. If you serve business customers that each need isolated access control, follow B2B Role Management.

B2C Role Management

For consumer-facing applications, RBAC is single-tier: you define roles and permissions once and assign them directly to your users.

The B2C RBAC Model

In B2C, RBAC is single-tier. Permissions are created once at the tenant level and bundled into roles — there is no organization layer. A role can then be assigned to a consumer in two ways: directly to the user, or through a Role Context — a named scope that bundles roles together with optional additional permissions and an expiration. Roles and permissions are managed through the same tenant routes used for B2B (see the API Reference below).

Concept	Scope	Notes
Permission	Tenant	The atomic unit of access (for example read:articles), created at the tenant level.
Role	Tenant	A named bundle of permissions, such as Free, Premium, or Moderator.
Role Context	Per user	An optional named scope that assigns roles to a consumer and may grant additional permissions and an expiration.
User (Consumer)	Tenant	Receives roles directly or through one or more role contexts; effective permissions are the union of those roles plus any additional permissions.

Key rules to keep in mind:

• Single-tier model. Permissions and roles live at the tenant level — there is no organization layer.
• Shared routes with B2B. Roles and permissions use the same management routes as B2B; only the assignment mechanism differs.
• Two ways to assign. A role can be assigned directly to a user, or via a Role Context that also grants context-specific extra permissions and an optional expiration.

Key Features

• Predefined User Roles – Assign roles like Admin, Moderator, or Standard User for structured access control.
• Granular Permissions – Define specific actions users can perform based on assigned roles.
• Dynamic Role Adjustments – Modify user roles based on behavioral triggers or subscription plans.
• Contextual Access Control – Enhance security by granting time-sensitive or location-based permissions.

Use Cases

1. Subscription-Tier Feature Gating

   • A media or SaaS app maps roles like Free, Premium, and Enterprise to permission sets that unlock features.
   • Upgrading or downgrading a subscription simply changes the user's role, instantly adjusting what they can access.

2. Community Platform Roles

   • A forum or content platform assigns Standard User, Moderator, and Admin roles.
   • Granular permissions ensure only moderators can hide posts and only admins can manage other users.

3. Contextual / Time-Bound Access

   • A consumer banking or rewards app grants temporary elevated permissions (for example, a promotional window) and revokes them automatically when the context expires.

Configuration

1. Navigate to Authorization > Roles & Permissions in the LoginRadius Admin Console.
2. Click Add Role to define a new role.
3. Assign permissions to the role.
4. Save the role and apply it within your application logic.

API Reference

B2C creates roles and permissions through the same tenant management routes as B2B (the Partner IAM API), and assigns them to users through the Role Context endpoints of the Customer Identity Roles Management API. These are server-side endpoints — call them with your API credentials, never from client-side code.

Action	Method	Endpoint
Create permission	POST	/v2/manage/permissions
Create role	POST	/v2/manage/roles
List roles	GET	/v2/manage/roles
Assign roles to a user (role context)	PUT	/identity/v2/manage/account/{uid}/rolecontext
Get a user's role contexts	GET	/identity/v2/manage/account/{uid}/rolecontext
Delete a role context	DELETE	/identity/v2/manage/account/{uid}/rolecontext/{rolecontextname}

Create a permission — POST /v2/manage/permissions

{
  "Name": "read:articles",
  "Description": "Read articles"
}

Create a role — POST /v2/manage/roles

{
  "Name": "premium",
  "Description": "Premium tier access",
  "Permissions": ["perm_23hi32n", "perm_238snu2"]
}

Assign roles to a user via a role context — PUT /identity/v2/manage/account/{uid}/rolecontext

{
  "rolecontext": [
    {
      "context": "Home",
      "roles": ["premium"],
      "additionalpermissions": ["read:articles"],
      "expiration": "07/15/2025 8:30:08 AM"
    }
  ]
}

Note: Manage roles and permissions through the Admin Console or these server-side APIs only. Never embed management API credentials in client-side code, and reference roles and permissions by their IDs rather than display names.

B2B Role Management (Partner IAM)

For B2B and Partner IAM, RBAC is two-tier, letting you serve many business customers from a single tenant while keeping each organization's access control isolated.

The Two-Tier RBAC Model

LoginRadius uses a two-tier hierarchy. Understanding which scope owns what is the key to using RBAC correctly: permissions are created only at the tenant level, tenant roles bundle them for use across every organization, and each organization can compose its own roles from that same permission catalog.

Concept	Scope	Who manages it	Notes
Permission	Tenant	Tenant admin	The atomic unit of access (for example read:users). Permissions can only be created at the tenant level.
Tenant Role	Tenant	Tenant admin	A reusable bundle of permissions available to every organization.
Organization Role	Organization	Org admin	An org-scoped role assembled from tenant permissions, isolated to that organization.
User (Member)	Organization	Tenant or org admin	Assigned one or more roles within an organization context; the same user can hold different roles in different organizations.

Key rules to keep in mind:

• Permissions are tenant-owned. Organizations consume permissions defined at the tenant level — they do not create their own permissions.
• Names must be unique. Permission names must be unique to avoid conflicts, and role names must be unique within their scope.
• A user can have at most one default role. The default role is assigned automatically whenever a user is created — on self-registration, when an admin adds them, or via Just-In-Time (JIT) provisioning — giving every member a baseline set of permissions.

Key Features

• Tenant-Level Roles & Permissions – Define organization-wide roles applicable across multiple sub-organizations.
• Organization-Level Customization – Allow each organization to create and manage its roles while inheriting tenant policies.
• Scalable Multi-Tenant Management – Seamlessly support large enterprises with multiple clients, vendors, or departments.
• Delegated Admin Controls – Assign administrative privileges to specific organizational users for self-managed access control.

Use Cases

1. Multi-Tenant SaaS Application

   • A SaaS-based project management tool enables companies to onboard their employees with custom roles like Manager, Team Lead, and Employee.
   • Each company defines its access policies while adhering to the tenant-wide security rules the SaaS provider sets.

2. E-Commerce Marketplace

   • Vendors selling products on a marketplace platform can assign roles like Store Owner, Sales Manager, and Customer Support Representative.
   • Granular permissions ensure only authorized users can manage inventory, process orders, and handle customer queries.

3. Healthcare Platform with Compliance Requirements

   • A healthcare provider uses role-based access to restrict doctors, nurses, and administrators from accessing sensitive patient records based on their roles.
   • HIPAA-compliant security policies are enforced through multi-factor authentication and permission-based role management.

4. Enterprise-Level Identity Management

   • A multinational corporation manages thousands of employees across subsidiaries with different organizational structures.
   • The IT department assigns roles dynamically based on department, seniority, and geographic location while allowing local offices to manage user access independently.

Configuration

B2B configuration follows the two-tier model: the tenant admin defines permissions and tenant roles, and an org admin composes organization-scoped roles from those permissions.

Step 1 — Tenant Admin: Create Permissions & Tenant Roles

1. Navigate to Authorization > Roles & Permissions in the LoginRadius Admin Console.
2. Open the Permissions section and click Add Permission. Enter a unique permission Name (for example read:users) and an optional description. Repeat for each granular action your product needs — typically the CRUD (Create, Read, Update, Delete) operations per resource.
3. To bundle permissions into a reusable role, click Add Role, enter a unique Role Name and description, select the permissions to include, and save. Tenant roles become available to every organization under your tenant.

Note: A single permission can be mapped to multiple roles, so define each permission once and reuse it freely across tenant and organization roles.

Step 2 — Org Admin: Create Organization Roles

1. Navigate to Admin Console > Organizations and select the organization.
2. Go to the Roles tab and click Create Role. Ensure the role name is unique.
3. Select the permissions for the role. Permissions are created only at the tenant level — if a permission you need does not exist yet, create it first under Authorization > Roles & Permissions (see Step 1), then return here to add it to the organization role.
4. Click Save. The role is scoped to this organization and can now be assigned to its users.

Note: To establish a default role, mark one role as default for the organization. The default role is assigned to a user automatically whenever the user is created — on self-registration, when an admin adds them, or via JIT provisioning — ensuring every member has a baseline set of permissions. A maximum of one role can be the default for any user.

Assigning Roles

1. Navigate to Organizations > Users in the Admin Console.
2. Select the user to whom you want to assign a role.
3. Choose one or more roles from the available options — the list includes both tenant roles and the organization's custom roles.
4. Save the assignment to enforce the access policy.

Note: Roles can also be utilized in Single Sign-On (SSO) configuration for role mapping. Configure a Custom IDP under Organizations > (select organization) > Features, then use the Group and Role Assignment section to map IdP groups to LoginRadius roles. This ensures users receive the correct permissions automatically upon signing in, simplifying access management across your organization.

API Reference

Roles and permissions can be managed programmatically through the Partner IAM API. Replace {orgId}, {uid}, and {id} with the relevant identifiers.

Action	Method	Endpoint
Create permission (tenant)	POST	/v2/manage/permissions
Create tenant role	POST	/v2/manage/roles
List tenant roles	GET	/v2/manage/roles
Set default role	PUT	/v2/manage/roles/{id}/default
Create organization role	POST	/v2/manage/organizations/{orgId}/roles
List organization roles	GET	/v2/manage/organizations/{orgId}/roles
Assign roles to a user (org context)	PUT	/v2/manage/account/{uid}/orgcontext/{orgId}/roles

Create a permission — POST /v2/manage/permissions

{
  "Name": "read:users",
  "Description": "Read users data"
}

Create a role (tenant or organization — same body shape) — POST /v2/manage/roles

{
  "Name": "Manager",
  "Description": "Can manage teams and view analytics",
  "Permissions": ["perm_23hi32n", "perm_238snu2"]
}

Assign roles to a user within an organization — PUT /v2/manage/account/{uid}/orgcontext/{orgId}/roles

{
  "RoleIds": ["role_dsag432d", "role_abc123"]
}

Note: Manage roles and permissions through the Admin Console or these server-side APIs only. Never embed management API credentials in client-side code, and reference roles and permissions by their IDs rather than display names.

Best Practices

These practices apply to both B2C and B2B deployments:

• Grant Only Necessary Access: Assign the minimum required permissions to reduce security risks.
• Review Permissions Regularly: Keep user roles updated as business needs evolve.
• Use Custom ID-based Authentication for Organizations: Adjust authentication settings at both the tenant and organization levels.
• Enable Single Sign-On (SSO) for Businesses: Allow seamless login integration with enterprise identity providers.
• Reference roles by ID in code: Avoid hardcoding role names; IDs are stable and prevent breakage when display names change.
• Personalize User Experience: Offer custom branding options for different organizations.

Related Resources

Partner IAMOrganizations ConfigurationPartner IAM APIsRoles Management API (B2C)Role Context API (B2C)Custom IDPConsumer Audit Logs