SendAuth uses a hierarchical role-based access control (RBAC) system that determines what actions users can perform. Roles have both inherent permissions and the ability to manage lower-tier roles.

Role Hierarchy

The roles are organized in a hierarchy where higher-level roles inherit all permissions from lower-level roles:

Admin > Registrar > Authenticator > None

Role Descriptions

Admin

Full access to the system

Admins have comprehensive control over the organization and can perform all actions available to lower-tier roles.

Permissions:

• Organization Management: Read and modify organization settings
• Permission Management: Create, modify, and delete permission labels
• Audit Access: View audit logs and system activity
• All Registrar permissions (inherited)

Common Use Cases:

• Organization owners or IT administrators
• Users who need to configure system-wide settings
• Those responsible for managing permissions and organizational structure

Registrar

Can manage users and authenticate users

Registrars focus on user lifecycle management and can handle user registration, modification, and authentication.

Permissions:

• User Management: Create, modify, and delete users
• All Authenticator permissions (inherited)

Common Use Cases:

• HR personnel managing employee accounts
• Team leads responsible for user onboarding/offboarding
• Support staff handling user account issues

Authenticator

Can authenticate users

Authenticators have read-only access to users and permissions, allowing them to verify user identities and access rights.

Permissions:

• User Access: Read user information and profiles
• Permission Viewing: View user permissions and groups
• All None permissions (inherited)

Common Use Cases:

• Support staff who need to verify user access
• Security personnel reviewing user permissions
• Service accounts for authentication systems

None

Can only authenticate themselves on request

The basic role with minimal permissions, typically assigned to standard users who only need to authenticate themselves.

Permissions:

• Self-authentication only
• No administrative capabilities

Common Use Cases:

• Standard end-users
• Newly created accounts before role assignment
• External users with limited access needs

Permission System

Role-Based Permissions

Each role comes with a predefined set of permissions that cannot be modified. These permissions are automatically granted based on the user’s role assignment.

Role Assignment

Who Can Assign Roles

• Admins can assign any role (Admin, Registrar, Authenticator, None)
• Registrars can assign lower roles (Authenticator, None)
• Authenticators can assign only the None role
• None users cannot assign roles

Role Management

Roles are assigned during:

• User creation (by users with appropriate permissions)
• User modification (by users with appropriate permissions)

Best Practices

Role Assignment Guidelines

1. Principle of least privilege: Assign the lowest role that provides necessary access
2. Regular review: Periodically audit user roles to ensure they remain appropriate
3. Temporary elevation: Use permission groups for temporary access rather than role changes

Security Considerations

• Role changes are logged in the audit system
• Higher-tier roles can manage lower-tier roles but not peers or superiors
• Custom permissions can extend but not restrict role-based permissions

Organizational Structure

• Use Admin role sparingly for organization owners and primary administrators
• Assign Registrar to managers and HR personnel
• Use Authenticator for support staff and service accounts
• Default new users to None until their access needs are determined