Authentication and Access Control

Authentication

Sylva uses a combination of custom authentication and Firebase Authentication for user login and session management.

Login Methods

Email/Password Login

• Users authenticate via the /SystemUsers/Login API endpoint
• Upon successful login, the system returns a userId and token
• The system then checks organization access via /SystemUsers/{userId}/checkOrgAccess/{organizationId}
• If the user has access to the organization, authentication proceeds

Firebase Authentication

• After successful login, Sylva uses Firebase Authentication for session management
• Custom tokens are generated via /SystemUsers/{userId}/fbAuthToken/{organizationId}
• The frontend signs in with the custom token using firebase.auth().signInWithCustomToken()
• Firebase handles session persistence and token refresh

Email Link Authentication

• Users can authenticate using email links sent to their email address
• The system supports password reset via email links

Current User API

The /SystemUsers/currentUser endpoint provides the current authenticated user’s information:

• Parameters: Optional _org parameter to specify organization context
• Response: User object containing:
  • User ID, name, email
  • Roles (system, organization, and course roles)
  • Organization information
  • Access permissions

The current user data is injected into all API requests and stored in the application state.

Session Management

• User sessions are managed through Firebase Authentication
• The current user is fetched on application initialization
• Organization context (_org) is automatically added to API request headers
• Session data is stored in the application state and persisted across page reloads

Access Control

Sylva implements a multi-level role-based access control (RBAC) system with three distinct role levels. While these role levels don’t follow a strict hierarchy, permissions are inherited based on the hierarchical context: System > Organization > Course.

Role Architecture

The three role levels are:

1. System Roles - Applied at the environment level (beta, production, etc.)
2. Organization Roles - Applied within an organization context
3. Course Roles - Applied within a specific course/project

System Roles

System roles are assigned at the environment level and apply across all organizations within that environment.

Role	Description	Storage
superadmin	Special role that allows access to the whole environment	MongoDB SystemAccess collection
developer	Adds special debugging options to all apps	MongoDB SystemAccess collection
sylvauser	Base role that all invited users inherit	MongoDB SystemAccess collection
creouser (deprecated)	Used to allow users to access CREO	MongoDB SystemAccess collection

Notes:

• System roles are assigned separately for each environment (e.g., beta, production, CH, US)
• Roles are injected into each user via the /currentUser API endpoint
• Role assignments are stored in a MongoDB collection called SystemAccess

Organization Roles

Organization roles control access and permissions within a specific organization.

Role	Description	Permissions
admin	Full organization access	Can create/delete courses, view/edit all courses in the org, access org settings
moderator	Content management access	Can view/edit all courses
auditor	Read-only access	Can view all courses, but cannot access the editor and cannot invite/delete users
creator	Limited creation access	Can create courses but does not have access to other courses except their own

Notes:

• Organization roles are assigned separately for each environment
• Roles are injected via the /currentUser API with an _org parameter
• The _org parameter is automatically added to all API request headers
• Role assignments are stored in a MongoDB collection called OrganizationAccess

Course Roles

Course roles control access and permissions within a specific course/project.

Role	Description	Permissions
owner	Full course control	Can edit/delete course - assigned automatically when you create the course
admin	Course administration	Can edit/delete course
staff	Course management	Can manage course
participant	Course participation	Can participate in a course

Notes:

• Course roles are assigned separately for each course/project
• Roles are injected via the /linkedProjects API endpoint
• Role assignments are stored in a MongoDB collection called ProjectAccess

Implementation Details

API Integration

All API requests automatically include:

• Authentication token from the current session
• Organization context (_org header) when available
• User role information injected via the /currentUser endpoint

Frontend Implementation

The authentication and access control system is implemented in the Vue.js frontend:

• Session Store: Manages current user state and authentication status
• API Interceptors: Automatically add organization context to requests
• Route Guards: Protect routes based on user roles and permissions
• Component Guards: Control component visibility and functionality based on roles

Data Storage

Role assignments are stored in MongoDB collections:

• SystemAccess - System-level role assignments
• OrganizationAccess - Organization-level role assignments
• ProjectAccess - Course/project-level role assignments

Each collection links users to their roles within the respective context.