Security Dimensions

Overview

The multi-dimensional security system operates on two orthogonal (independent but combinable) security dimensions. Each dimension controls access to different aspects of the data, and they can be combined for fine-grained authorization.

Dimension 1: Organizational Access

Concept

Organizational access controls which organization’s data a user can view or modify. This implements a multi-tenant model where users can participate in multiple organizations with different permission levels.

Structure

OrgUser → [Primary Organisation] + [Linked Organisations with permissions]

Rules

  • Every user belongs to ONE primary organization

  • Users have FULL ACCESS (READ_WRITE) to their primary organization

  • Users can be granted access to MULTIPLE secondary organizations

  • Each secondary organization link has an explicit access level: READ or READ_WRITE

  • Access can be time-bound (validFrom/validTo) and can be activated/deactivated

Example

John (OrgUser) → Primary: Running Club A (READ_WRITE - implicit)
                → Linked: Running Club B (READ)
                → Linked: Athletics Federation (READ_WRITE)

In this example:

  • John can fully manage data in Running Club A (his primary organization)

  • John can view but not modify data in Running Club B

  • John can view and modify data in Athletics Federation

Use Cases

Scenario Access Pattern

Club Administrator

Primary: Their club (READ_WRITE) + Linked: None

Federation Official

Primary: Federation (READ_WRITE) + Linked: Multiple member clubs (READ)

Multi-Club Athlete

Primary: Main club (READ_WRITE) + Linked: Second club (READ or READ_WRITE)

Event Organizer

Primary: Organizing body (READ_WRITE) + Linked: Participant clubs (READ)

Dimension 2: Personal Data Access

Concept

Personal data access controls which individuals' personal information a user can view or modify. This implements a delegation model where principals can grant access to their data or access others' data through explicit links.

Structure

Principal (Person) → [Self - implicit] + [Linked Persons with permissions]

Rules

  • Every user has ONE principal person (their own identity)

  • Users have FULL ACCESS (READ_WRITE) to their own personal data (implicit)

  • Principals can be linked to OTHER persons via delegation

  • Each person link has an explicit access level: READ or READ_WRITE

  • Links are typed (FAMILY, TEAM_MANAGER, COACH, etc.)

  • Access can be time-bound and activated/deactivated

Example

Family Scenario

Sarah (Principal) → Self: Sarah (READ_WRITE - implicit)
                  → Child: Emma (READ_WRITE via FAMILY link)
                  → Child: Jack (READ_WRITE via FAMILY link)

Sarah can:

  • Manage her own profile and data

  • Create and manage profiles for her children

  • Enter her children into events

  • Manage payment information for the family

Team Manager Scenario

Mike (Team Manager) → Self: Mike (READ_WRITE - implicit)
                    → Team: Player 1 (READ via TEAM_MANAGER link)
                    → Team: Player 2 (READ via TEAM_MANAGER link)
                    → Team: Player 3 (READ via TEAM_MANAGER link)

Mike can:

  • Manage his own data

  • View team members' profiles

  • Enter team members into events

  • View (but not modify) team members' personal information

Coach Scenario

Coach Jane → Self: Jane (READ_WRITE - implicit)
          → Athlete: Tom (READ_WRITE via COACH link)
          → Athlete: Lisa (READ_WRITE via COACH link)

Jane can:

  • Manage her own data

  • Manage athlete profiles and training data

  • Update performance information

  • Modify athlete entries and results

Link Types

Link Type Typical Use Case Common Access Level

FAMILY

Parent managing children’s accounts

READ_WRITE

TEAM_MANAGER

Team manager viewing team roster

READ

COACH

Coach managing athlete data

READ_WRITE

GUARDIAN

Legal guardian for another person

READ_WRITE

DELEGATE

General delegation (temporary access)

READ or READ_WRITE

Security Matrix

The two dimensions can be visualized in a matrix:

┌──────────────────────────────────────────────────────────────┐
│                    SECURITY MATRIX                           │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  DIMENSION 1: ORGANIZATIONAL ACCESS                          │
│  ═══════════════════════════════                             │
│                                                              │
│  Controls: Which organization's data?                        │
│  Granularity: Per organization                               │
│  Access Levels: READ, READ_WRITE                             │
│  Default: Primary organization (READ_WRITE)                  │
│                                                              │
├──────────────────────────────────────────────────────────────┤
│  DIMENSION 2: PERSONAL DATA ACCESS                           │
│  ══════════════════════════════════                          │
│                                                              │
│  Controls: Which person's data?                              │
│  Granularity: Per person                                     │
│  Access Levels: READ, READ_WRITE                             │
│  Default: Self (READ_WRITE)                                  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Combining Dimensions

For entities that implement both organizational and personal security interfaces (composite-scoped entities), each dimension is checked independently and BOTH must grant access:

Access Granted = (Has Org Access) AND (Has Person Access)

Example: Event Entry

An EventEntry links a person to an event:

  • Event belongs to an organization

  • Person is the participant

To access an EventEntry, the user must have:

  1. Access to the event’s organization (org dimension)

  2. Access to the participant’s person data (person dimension)

User: Sarah
Org Access: Club A (READ_WRITE), Club B (READ)
Person Access: Self, Child Emma (READ_WRITE)

EventEntry: Emma entering Event in Club A
✓ Can access: Has org access (Club A) AND person access (Emma)

EventEntry: Emma entering Event in Club C
✗ Cannot access: No org access to Club C (even though has person access)

EventEntry: Other child entering Event in Club A
✗ Cannot access: Has org access but no person access

Access Levels

Both dimensions use the same access level enumeration:

Level Capabilities

READ

View/query data only. Cannot create, update, or delete.

READ_WRITE

Full access: view, create, update, and delete.

Access Level Hierarchy

READ_WRITE satisfies READ requirements:

READ requirement:
  - READ access: ✓ Grants access
  - READ_WRITE access: ✓ Grants access

READ_WRITE requirement:
  - READ access: ✗ Insufficient
  - READ_WRITE access: ✓ Grants access

Special Cases

Admin Bypass

System administrators (ROLE_ADMIN) bypass all security restrictions:

  • Can access all organizations

  • Can access all persons' data

  • No explicit grants needed

Global Viewers

Users with ROLE_GLOBAL_VIEWER or ROLE_AUDITOR can read all organizations but cannot write:

  • Org dimension: READ access to all organizations

  • Person dimension: Still restricted to linked persons

Self-Access

Users always have implicit READ_WRITE access to:

  • Their own personal data (person dimension)

  • Their primary organization (org dimension)

No explicit grants needed for self-access.

Next Steps