Skip to content

redfish authx

Jump to bottom
Pola, Sudhir edited this page Nov 17, 2025 · 4 revisions

Redfish Authorization and Authentication support in DMT Console

Table of Contents

  1. Requirements Overview
  2. Redfish HTTP Basic Authentication Design
  3. Future Support

Requirements Overview

Redfish Authentication and Authorization requires compliance with the DMTF Redfish Specification, specifically sections on Authentication and Authorization as described below:

  1. DSP0266 - 13.3 Authentication
  2. DSP0266 - 13.4 Authorization

Below is a quick summary of what the Redfish Specification mentions w.r.t Authentication:

  1. The service shall support both HTTP Basic authentication and session-login authentication via the Redfish session service
  2. All communication for authentication (and presumably management) shall use TLS (i.e., HTTPS) when using Basic authentication or session creation.
  3. The service shall not use HTTP cookies for authentication of standard operations (GET/POST/PUT/PATCH/DELETE).
  4. For session login: the client issues a POST to the Sessions collection URI (e.g., /redfish/v1/SessionService/Sessions) over HTTPS, with credentials in the body. Then the service returns a session token (typically returned in X-Auth-Token header) and that token is used in subsequent requests.
  5. When using Basic authentication, support connections that conform to TLS/HTTPS.

Below is a quick summary of what the Redfish Specification mentions w.r.t Authorization:

  1. Authorization is composed of a privilege model (users → roles → privileges) and an operation-to-privilege mapping (which operations require which privileges)
  2. Privilege Model:
    • Authorization is role-based — users → roles → privileges.
    • Roles (e.g., Administrator, Operator, ReadOnly) define AssignedPrivileges and optional OemPrivileges.
    • Roles may be standard, OEM-defined, or restricted to limit privilege escalation.
  3. Operation-to-Privilege Mapping:
    • Each REST operation (GET, POST, PATCH, DELETE, etc.) is authorized based on required privileges defined in a Privilege Registry.
    • Supports property overrides, subordinate overrides, and URI-specific overrides for fine-grained control.
    • Privilege checks use logical AND/OR combinations as specified per operation.
  4. OAuth2 Support (Optional):
    • Bearer tokens can convey roles/privileges via scope claims (Redfish.Role., Redfish.Privilege.).
  5. Compliance: Services must enforce least-privilege access and prevent privilege escalation across all authorization paths.

Authentication and Authorization Support Publication

  1. Discovery via Service Root : The service's Service Root (/redfish/v1/) resource shall advertise authentication and session capabilities through its links. It typically contains:

    • Links/Sessions → points to the SessionService or directly to the Sessions Collection (/redfish/v1/SessionService/Sessions).
    • AccountService → points to where user and role management is defined (/redfish/v1/AccountService).

  2. Session Service : The SessionService resource (/redfish/v1/SessionService) describes:

    • Whether session-based authentication is supported (ServiceEnabled property).
    • The maximum number of sessions allowed (SessionTimeout, MaxConcurrentSessions).
    • Link to the Sessions Collection, where clients can create a session by POSTing credentials.
    Example:

{
"@odata.id": "/redfish/v1/SessionService",
"Id": "SessionService",
"ServiceEnabled": true,
"SessionTimeout": 600,
"Sessions": { "@odata.id": "/redfish/v1/SessionService/Sessions" }
}

  3. Supported Authentication Mechanisms: The Redfish service shall support HTTP Basic authentication and Redfish session-based login (per DSP0266 §13.3). If OAuth 2.0 is supported, this is advertised under:

    • /redfish/v1/AccountService/Oem/ or
    • /redfish/v1/AccountService/ExternalAccountProviders/ which may include OAuth2 configuration endpoints and token service references.

  4. Authorization Support Publication is done through the AccountService and Role Resources. The AccountService (/redfish/v1/AccountService) resource publishes:

    • Supported roles (Roles collection link).
    • Supported privileges for each role (AssignedPrivileges, OemPrivileges).
    • Authentication mode and external providers (if any).
    • Each Role resource describes:

    { "Id": "Administrator", "AssignedPrivileges": ["Login", "ConfigureManager", "ConfigureUsers", "ConfigureComponents", "ConfigureSelf"], "IsPredefined": true }

  5. Privilege Registry: The Privilege Registry is a published JSON schema (often under /redfish/v1/Registries/PrivilegeRegistry) that defines:

    • Which privileges are required for each resource type and HTTP operation.
    • Property-level and URI-specific overrides.
    • Logical privilege combinations (AND/OR).
    • This makes authorization self-describing, allowing clients and management tools to query and understand access requirements dynamically.

  6. OAuth 2.0 Publication (if supported) is exposed through:

    • /redfish/v1/AccountService/OAuth2 (lists supported grant types, token URLs, scopes, etc.)
    • /redfish/v1/AccountService/ExternalAccountProviders (for linking external identity sources).

Redfish HTTP Basic Authentication Design

The DMT Console Redfish Component implements HTTP Basic Authentication per RFC 7617 and DMTF Redfish Specification DSP0266 §13.3.

1. Authentication Support Advertisement

Redfish Basic Authentication is advertised through the OpenAPI specification using standard security schemes.

Security Scheme Definition:

BasicAuth:
  type: http
  scheme: basic
  description: HTTP Basic Authentication for Redfish API

Endpoint-Level Security:

  • Public Endpoints: Service root (/redfish/v1/) and metadata (/redfish/v1/$metadata) - No authentication required (DMTF compliance)
  • Protected Endpoints: All other /redfish/v1/* resources - Basic Auth required

Design Rationale: This approach ensures DMTF Redfish specification compliance where the service root must be publicly accessible for service discovery.

2. Redfish OpenAPI HTTP Basic Authentication Implementation Workflow

graph LR
   A[Redfish OpenAPI<br/>Schemas] --> B[Schema Merge<br/>Process]
   B --> C[Security<br/>Injection]
   C --> D[Code<br/>Generation]
   D --> E[Auth-Ready<br/>Server]
Loading

Workflow Steps:

  1. Schema Consolidation: Multiple Redfish OpenAPI YAML files are merged into a unified specification
  2. Security Enhancement: BasicAuth security scheme is injected into the OpenAPI specification
    • Adds BasicAuth definition to security schemes
    • Applies security requirements to protected endpoints
    • Marks public endpoints with no authentication
  3. Code Generation: Authentication-aware server code is generated from the enhanced specification

3. Redfish HTTP Basic Authentication Integration Points

graph TD
    A[DMT Console Redfish Module Initialization] --> C[HTTP Basic Auth Middleware<br/>Registration]
    C --> D{Endpoint<br/>Classification}
    D -->|Public| E[Direct Access<br/>No Auth]
    D -->|Protected| F[BasicAuth<br/>Middleware]

    F --> G{Validation}
    G -->|Valid| H[Process Request]
    G -->|Invalid| I[401 Unauthorized]
Loading
  • Component-Level Integration: Authentication middleware is registered at the Redfish Component level, not globally
  • Route-Specific Application: Middleware is selectively applied based on endpoint classification
  • Isolation Principle: Redfish authentication remains independent from other DMT Console services

Key Design Benefit: This ensures Redfish endpoints use Basic Authentication while other services can use different authentication mechanisms (e.g., JWT) without cross-contamination.

4. Configuration Structure

Redfish HTTP Basic Authentication Credentials use the existing DMT Console Configurations

auth:
  disabled: "false/true"
  adminUsername: <DMT Console Admin Username>
  adminPassword: <DMT Console Admin Password>

5. Authentication Sequence Flow

Complete Authentication Flow:

sequenceDiagram
    participant Client as Redfish Client
    participant Auth as Auth Middleware
    participant Service as Redfish Service

    Note over Client,Service: Scenario 1: Public Endpoint Access
    Client->>Auth: GET /redfish/v1/<br/>(no credentials)
    Auth->>Auth: Check endpoint classification
    Note over Auth: Public endpoint detected
    Auth->>Service: Forward request
    Service-->>Client: 200 OK<br/>Service Root JSON

    Note over Client,Service: Scenario 2: Protected Endpoint - Valid Credentials
    Client->>Auth: GET /redfish/v1/Systems (Authorization: Basic <credentials>)
    Auth->>Auth: Check endpoint classification
    Note over Auth: Protected endpoint
    Auth->>Auth: Extract & validate credentials (constant-time comparison)
    Note over Auth: Credentials valid
    Auth->>Service: Forward request
    Service-->>Client: 200 OK Systems Collection JSON

    Note over Client,Service: Scenario 3: Protected Endpoint - Invalid Credentials
    Client->>Auth: GET /redfish/v1/Systems<br/>(Authorization: Basic <invalid>)
    Auth->>Auth: Check endpoint classification
    Note over Auth: Protected endpoint
    Auth->>Auth: Extract & validate credentials
    Note over Auth: Credentials invalid
    Auth-->>Client: 401 Unauthorized DMTF Error Format
Loading

Flow Characteristics:

  • Public Endpoint Handling: Service root and metadata are immediately accessible without authentication
  • Protected Endpoint Handling: All other endpoints require valid Basic Auth credentials
  • Security Validation: Constant-time comparison prevents timing attacks
  • DMTF Compliance: Error responses follow Redfish specification format

3. Future Support

Planned Enhancements:

  1. The JWT Based Authentication supported by DMT Console to be made available through the Redfish Sessions and Redfish Account Service
  2. The Authorization Support through Redfish

1. Overview of DMT Support for JWT

The DMT Console implements a unified, simple authentication architecture using configuration-based credentials and JWT tokens for all client types as shown below:

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Web Browsers  │    │   API Clients   │    │ Other  Clients  │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │ JWT Token (Authorization: Bearer)
                                 ▼
               ┌─────────────────────────────────────┐
               │         Authentication Layer        │
               │    ┌───────────────────────────┐    │
               │    │      JWT Validator        │    │
               │    │   (config.yml creds)      │    │
               │    └───────────────────────────┘    │
               └─────────────────────────────────────┘
                                 │
                                 ▼
               ┌─────────────────────────────────────────────┐
               │         Protected Resources                 │
               │  • Web UI          • Redfish APIs(future)   │
               │  • REST APIs       • Device Mgmt            │
               └─────────────────────────────────────────────┘

2. Current Login Flow (Configuration-Based Authentication)

sequenceDiagram
    participant Client as Web/API Client
    participant Gateway as Auth Gateway
    participant Config as Configuration
    participant JWT as JWT Service
    participant Protected as Protected Resource

    Client->>Gateway: 1. POST /api/v1/authorize {username, password}
    Gateway->>Config: 2. Check adminUsername/adminPassword
    Config-->>Gateway: 3. Credentials validated
    Gateway->>JWT: 4. Generate JWT token
    JWT-->>Gateway: 5. Signed JWT token
    Gateway-->>Client: 6. 200 OK {token: "eyJhbGc..."}

    Note over Client,Gateway: Subsequent authenticated requests
    Client->>Gateway: 7. GET /api/v1/devices (Authorization: Bearer eyJhbGc...)
    Gateway->>JWT: 8. Validate JWT token
    JWT-->>Gateway: 9. Token valid
    Gateway->>Protected: 10. Forward request
    Protected-->>Gateway: 11. Response
    Gateway-->>Client: 12. 200 OK {response}
Loading

Current Implementation Notes:

  • No user database table exists
  • Single admin user from configuration: auth.adminUserName and auth.adminPassword
  • Same JWT token used for both web UI and API access
  • No session management - stateless JWT only

Console Wiki

Clone this wiki locally