The Link system implements Role-Based Access Control (RBAC) through a claims-based authorization model. Currently, the system has a single "Admin" role configured which has access to all available permissions.

sequenceDiagram
    participant User as Application / User
    participant API as Link Admin API
    participant IDP as Identity Provider
    participant Account as Account Service

    User->>API: /api/login
    API->>IDP: Back channel request to /authorize endpoint
    API-->>User: Redirect to Identity Provider login
    User->>IDP: Authenticates
    IDP-->>API: Access Token
    API->>IDP: Back channel request to /userinfo endpoint
    IDP-->>API: Identity Token
    API->>Account: Back channel request to /account/api/user endpoint
    Account-->>API: Link User Claims
    API-->>User: Link Cookie *

    note over User,API: *Link Cookie is a session cookie with no expiration date set
    note over Account: Supported authentication schemes: OAuth, OpenIDConnect, JWT Bearer

Inter-service Authentication

Inter-service authentication is enforced using symmetric signing key on a token that is generated by the BFF and passed in requests to each of the micro-services.

Each service is provided access to the same signing key via the Secret Manager to sign tokens that are generated by each service.

There are two implementations of the Secret Manager:

• Azure Key Vault: Uses a centralized/cloud-based key vault to store the symmetric signing key.
• Local Secret Manager: Uses a per-service configuration to define the symmetric signing key used by each service.

The BFF has an option to LinkTokenService:EnableTokenGenerationEndpoint which allows users that are authenticated in the BFF to generate a token that can be passed directly to the micro services (for debugging purposes, for example). However, this should not (generally) be enabled in a production environment. In a production environment the BFF should be the only exposed service and the BFF would be responsible for proxying requests to each of the micro services.

When proxying a request from the BFF to micro services that were initiated by a user, the Yarp Proxy automatically generates a token to be passed in that proxy'd request to the micro service. You can control the life-span of the micro-service tokens generated by the BFF using the LinkTokenService:TokenLifespan property. The LinkTokenService:LogToken property creates log entries when these tokens are generated by the BFF for debugging purposes.

Claims/Permissions

The following claims define what actions users can perform in the system:

Roles

Currently, only a single role is configured in the system:

Admin Role

• Has access to all claims/permissions listed above
• Full system administrative capabilities
• No tenant-level restrictions

Implementation

The RBAC system is implemented through:

• Claims defined in LinkSystemPermissions enum
• Authorization policies that map to individual claims
• Role and user entities that maintain claim assignments
• Claims-based authorization checks in the application

Future Considerations

Expanded Claims

The system is designed to support additional claims, particularly:

• UI-specific permissions for granular interface control
• Additional operational permissions as new features are added
• Workflow-specific permissions

Additional Roles

Plans for expanding role definitions include:

• Creating non-administrative roles with limited permissions
• Role hierarchies
• Custom role definitions per tenant

Tenant Restrictions

Future updates will include:

• Tenant-specific role definitions
• User-to-tenant mapping
• Tenant-scoped permissions
• Multi-tenant authorization policies

Relationships

flowchart LR
nsecurity_5C9FF1FF["Design: Security"]