Google Sign-In Required

Use your company Google account to access the BetterFleet private content.

Back to private home

BetterFleet Support Private
Skip to content
BetterFleet Dev Wiki
Core Model
Initializing search
    bf-dev
    • Home
    • Product Capabilities
    • Process
    • Current Work
    • System Design
    • Software Reference
    • Operations
    bf-dev
    • Home
      • Overview
      • Manage
      • Overview
      • Product Engineering Workflow
      • Product Engineering Delivery
      • Product Engineering Workflow in Linear
        • GitLab Feature Flags
        • In-App Docs Authoring
        • Release Notes
      • Templates
      • Publishing
      • Workflow Companions
      • Overview
      • Active Artifacts
      • Backlog Artifacts
      • Archived Artifacts
      • Overview
      • Microgrid
      • OSCP
        • Challenge
        • Specification
        • Spec
        • Architecture
        • Overview
        • Script Runtime Model
        • Compose Profiles and Modes
        • Repo Topology
        • CI and Release Integration
        • Overview
        • Internal Application Diagrams
          • Overview
          • Web Model
          • Core Model
            • Authentication
            • Authorization dependency model
            • Permission caches at app startup
            • Workspace scoping signals
            • Public vs protected API surfaces
        • Service Interaction Flows
        • Data and State
          • Index
          • bf-manage-web
          • bf-manage-core
          • bf-manage-connect
          • bf-manage-sitepwrmon
          • bf-manage-incidents
          • bf-telematics
          • bf-depot-sim
          • bf-manage-roaming
          • bf-support-microsite
          • bf-digital-twin
          • bf-schedule-creator
        • Overview
        • Internal Application Diagrams
        • Migration and Flags
        • Simulation Request Lifecycle
          • Index
          • bf-bnl-ui
          • bf-bnl-settings
          • bf-bnl-schedule-analysis-compute
          • bf-route-modelling
          • bf-schedule-creator
          • bf-digital-twin
        • Overview
        • Secrets and Env Strategy
        • Vendors and Local Dependencies
        • ADRs
        • Service Matrix
        • Cloud Dependencies
        • Ports and URLs
      • Onboarding
      • Daily Operations Runbook
        • Overview
        • Staging Hotfix Release
        • Production Hotfix Release
        • Terraform Plan Dry Runs
      • Troubleshooting
      • Testing Guide
    • Authentication
    • Authorization dependency model
    • Permission caches at app startup
    • Workspace scoping signals
    • Public vs protected API surfaces

    bf-manage-core Auth and Authorization Model¶

    Authentication¶

    authenticate (src/auth/authentication.py) supports:

    • Cognito bearer JWT path
    • legacy VEMO token fallback path
    • machine to machine token detection

    On success it writes request.state.user with principal metadata.

    flowchart TD
      Header[Authorization input] --> Parse[Parse token source]
      Parse --> Cognito{Cognito decode ok}
      Cognito -- Yes --> Principal[Build principal]
      Cognito -- No --> Legacy[Try legacy token decode]
      Legacy --> LegacyOk{Legacy decode ok}
      LegacyOk -- Yes --> Principal
      LegacyOk -- No --> Reject[Return 401]

    Authorization dependency model¶

    Most routers are mounted with Depends(auth.authenticate) in main.py. Endpoint-level access control is enforced via authorise(...) dependency (src/auth/permissions.py).

    authorise performs:

    1. principal sanity checks
    2. system and m2m bypass checks
    3. workspace resolution from resource mapping or request headers
    4. user workspace permission lookup
    5. role and CRUD action checks
    flowchart TD
      Principal[request state principal] --> Active{Principal active}
      Active -- No --> Deny[403 inactive]
      Active -- Yes --> ResolveWorkspace[Resolve workspace id]
      ResolveWorkspace --> PermCache[Check workspace permission cache]
      PermCache --> RoleCache[Resolve role from role cache]
      RoleCache --> RuleCheck[Apply action and condition rules]
      RuleCheck --> Allow[Allow request]
      RuleCheck --> Deny

    Permission caches at app startup¶

    main.py populates app state caches:

    • workspace_id_mapping
    • role_cache
    • workspace_permission_cache

    These accelerate authorization checks and are reloaded on cache misses.

    flowchart LR
      Startup[App startup] --> Map[workspace id mapping cache]
      Startup --> Roles[role cache]
      Startup --> Perms[user workspace permission cache]
      RequestAuth[authorise check] --> Map
      RequestAuth --> Roles
      RequestAuth --> Perms

    Workspace scoping signals¶

    Workspace can be inferred from:

    • resource identifier in path/query/body and mapping table
    • x-account-id header for specific checks and context

    This is how multi-tenant account boundaries are enforced per request.

    Public vs protected API surfaces¶

    main.py includes:

    • public auth routes without global auth dependency
    • public API routes with auth dependency
    • internal API routes with auth dependency

    Authorization is still endpoint-specific via explicit authorise(...) usage.

    Made with Material for MkDocs