Key Groups & Access Rules

The Atslegas (ARS) system utilizes a Role-Based Access Control (RBAC) model combined with logical Key Grouping to manage physical security and inventory efficiently. This ensures that only authorized personnel can view, manage, or issue keys within the Riga State German Grammar School environment.

User Roles & Permissions

The system defines four distinct roles that determine what a user can see and do within the application.

| Role | Access Level | Permissions | | :--- | :--- | :--- | | Root | Superuser | Full system access, including initial configuration and emergency overrides. | | Admin | Management | Access to the Admin Dashboard, user creation, key group management, and log editing. | | User | Operational | Access to the user frontend to view key availability and perform basic check-in/check-out actions. | | Person | Registry | A record of a physical individual (e.g., a student or teacher) who can be assigned keys but does not necessarily have login credentials. |

Key Groups

Key Groups are logical containers used to organize the school's inventory. Instead of managing permissions for every single key, administrators can group keys by location, department, or function.

Managing Groups via the Dashboard

Administrators can manage these groups through the Admin Groups interface:

1. Creation: Define a name (e.g., "Science Lab" or "Old Building").
2. Assignment: Link specific keys to the group using their unique IDs.
3. Permissions: Assign specific users or "persons" to a group to define who is authorized to interact with those specific keys.

Programmatic Group Management

For automation or bulk updates, the system provides a RESTful API.

Add a Key Group

POST /api/keyGroup/add

Request Body:

{
    "name": "Library West Wing",
    "users": [],
    "keys": ["K-101", "K-102"],
    "persons": []
}

Success Response: 201 Created

Access Rules & Session Security

Access is governed by several automated security layers:

1. Session Lifecycle

By default, the system enforces a server-side session timeout.

• Timeout Duration: 3600 seconds (1 hour), configurable in config.json.
• Activity Tracking: Every request updates the last_activity timestamp. If a session exceeds the PERMANENT_SESSION_LIFETIME, the user is automatically logged out and must re-authenticate.

2. Authorization Checks

The API enforces strict checks on every request (excluding the login endpoint and public frontend assets). If a user attempts to access an endpoint without a valid user_id in their session, the server returns a 401 Unauthorized error.

3. String Limits

To prevent database injection and UI breakage, the system enforces strict character limits on access-related fields:

• Username/Password: Maximum 64 characters.
• Group Names: Maximum 64 characters.

Configuration

Access rules and database constraints are managed in the config.json file:

{
    "client_sessions": {
        "timeout_seconds": 3600
    },
    "users": {
        "username_length_limit": 64,
        "password_length_limit": 64
    }
}