Understanding Role-Based Access Control (RBAC) Permissions

RBAC Overview

Lynio IAM uses a Role-Based Access Control (RBAC) model to enforce security boundaries and separate administrative privileges within a tenant.

Under this model:

1. Permissions represent granular, individual actions that can be performed on the platform (e.g., lynio.iam:user:write or lynio.cloud:compute:instance:read).
2. Roles act as logical groupings of these permissions (e.g., User Manager contains user-management permissions).
3. Users are assigned one or more roles. The system aggregates these roles to determine the user's total set of permissions.

Permission Format

Permissions follow structured, namespaced patterns depending on the service:

1. Identity & Access (IAM)

lynio.iam:<resource>:<action>

• Namespace (lynio.iam): Scopes the permission to the Identity and Access Management service.
• Resource: The resource category being managed (user, role, application, settings).
• Action: The operation being permitted (read or write). Note that the write action is inclusive of create, update, and delete actions.

2. Platform Core Services (Cloud)

lynio.cloud:<service>:<resource>:<action>

• Namespace (lynio.cloud): Scopes the permission to the Platform Core services.
• Service: The backend service category (compute, network, storage, region).
• Resource: The granular resource type (e.g., instance, vpc, volume, node).
• Action: The permitted operation (read or write).

Wildcard Logic

To simplify administration, prefix and middle wildcard matching using the asterisk (*) character is supported:

• Global Admin (*): Matches all resources and all actions across the entire platform.
• Service Admin (lynio.iam:* or lynio.cloud:*): Matches all resources and actions within the respective service.
• Resource Admin (lynio.cloud:compute:instance:*): Matches both read and write actions for virtual machine instances.
• Middle Wildcard (lynio.cloud:*:*:read): Matches all read actions across all services and resources.

Available Permissions Reference

1. Identity (IAM) Permissions

2. Platform Core Services (Cloud) Permissions

3. AI & Machine Learning Permissions

4. Support & ITSM Permissions

Default Tenant Roles

When a new tenant is provisioned, Lynio IAM automatically seeds three default roles:

1. Administrator

• Permissions: ["*"]
• Purpose: Full control over the tenant. Automatically assigned to the initial bootstrap administrator account.

2. User Manager

• Permissions: ["lynio.iam:user:*", "lynio.iam:role:read"]
• Purpose: Designed for HR/operations personnel to create and manage user accounts, reset credentials, and assign existing roles to users. They cannot modify or create new roles.

3. Viewer

• Permissions: ["lynio.iam:*:read", "lynio.cloud:*:*:read"]
• Purpose: Auditing and read-only access. All write actions are blocked at the API level, and creation/modification controls are hidden in the LYNIO Console.

Console Permissions Directory

To make role creation easy, LYNIO Console includes an interactive Permissions Directory:

1. Under the Roles & Groups tab, click Permissions Directory at the top.
2. In the modal, you can search and filter the list of permissions by name, category, or description.
3. Click the copy icon next to any permission to copy it to your clipboard, then paste it directly into your role's permission list.

Developer Integration

1. Retrieving Available Permissions via API

Applications can query the list of available platform permissions dynamically:

• Endpoint: GET /api/v1/permissions
• Headers: Authorization: Bearer <token>
• Response:

[
  {
    "value": "*",
    "category": "Identity (IAM)",
    "description": "Super Administrator. Full access to all actions and resources across the platform."
  },
  {
    "value": "lynio.cloud:compute:instance:read",
    "category": "Compute",
    "description": "View virtual machine instances, check status, and read console logs."
  }
]

2. Inspecting Token Claims

When a user logs in, their access token (JWT) contains their aggregated permissions in the permissions claim:

{
  "sub": "user_12345",
  "email": "user@example.com",
  "tenant_id": "tenant_abc",
  "permissions": [
    "lynio.iam:user:*",
    "lynio.cloud:compute:instance:read"
  ],
  "iss": "https://iam.lynio.cloud",
  "exp": 1716300000
}

3. Middleware Validation Example (Go)

To validate permissions in your custom microservices, you can implement a wildcard-compliant matcher like the one used in Lynio IAM:

package middleware

import (
	"path"
)

func HasPermission(userPerms []string, requiredPerm string) bool {
    for _, p := range userPerms {
        if p == "*" {
            return true // Global Admin bypass
        }
        if matched, _ := path.Match(p, requiredPerm); matched {
            return true // Glob pattern matching (handles suffix and middle wildcards like lynio.cloud:*:read)
        }
    }
    return false
}

Self-Service Actions (Always Allowed)

Certain endpoints bypass RBAC checks because they are scoped strictly to the authenticated user's own profile context. Regardless of permissions, any logged-in user is authorized to:

• GET /api/v1/auth/profile: View their own profile details.
• PUT /api/v1/auth/profile: Update their name and telephone number.
• POST /api/v1/auth/change-password: Update their password (requires verifying the current password).
• POST /api/v1/auth/mfa/setup / /verify / /disable: Enroll and manage their personal TOTP MFA settings.