/
Multiple Authentication Types

Multiple Authentication Types

Multiple Authentication Types Design

  • Status: Draft / Review / Approved / Implemented / Abandoned

Stakeholders

  • Developers: Jonah Rosenblum, Ted Dunning

  • Component validation engineer(s): TBD

  • Reviewers: @Michael MacDonald, @Tom Nabarro, @Johann Lombardi, @Liang Zhen, @Kris Jacque

Problem Statement

DAOS currently supports AUTH_SYS only. That model derives identity from Unix UID/GID context and works well for traditional bare-metal Unix, but it does not map cleanly to deployments that span containers, VMs, external cloud environments, or identity systems that are not based on local Unix accounts.

Why Current Design Cannot Support Multi-Auth

  • The server cannot specify which authentication type it requires, implicitly AUTH_SYS.

  • There is no mechanism for a client to discover which authentication method the server requires.

  • Supporting a non-Unix identity source requires changes to the token path, the agent, and the server validation path.

  • DAOS ACLs already support non-Unix principals, but the authentication pipeline is effectively hard-wired to the built-in Unix domain.

This design introduces a generic authentication framework that preserves current AUTH_SYS behavior by default while allowing DAOS to support additional authentication types.

Goals

  • Preserve existing AUTH_SYS behavior for unchanged deployments.

  • Allow the server to configure and enforce any supported authentication flavor.

  • Allow clients to discover the server's configured authentication flavor and request credentials of that flavor.

  • Support switching authentication flavors without reformatting storage.

  • Preserve existing ACL semantics and the principal format id@[domain].

  • Prevent cross-flavor and cross-domain spoofing.

  • Keep the wire format backward-compatible when the server remains configured for AUTH_SYS.

Non-Goals

  • Redesigning DAOS ACL semantics.

  • Making old clients work against a system that has been switched to a non-AUTH_SYS flavor.

Key Design Decisions

  • One active authentication flavor per DAOS server.

  • AUTH_SYS remains the default when auth configuration is absent.

  • Each authentication flavor has one implicit principal domain. For example, AUTH_SYS maps to id@ and AUTH_ACCMAN maps to id@accman.

  • All authentication flavors use one common DAOS token envelope (AUTH_SYS token format can be generalized).

  • Flavor-specific material is carried in a flavor-specific blob inside that common envelope.

Current Behavior

The current behavior is preserved for existing deployments:

  1. The client requests an AUTH_SYS token from the local agent.

  2. The agent derives Unix identity from the local connection.

  3. The agent signs a DAOS token.

  4. The client presents the token to the server.

  5. The server validates the token and evaluates ACLs using principals in the built-in AUTH_SYS domain.

Proposed Design

Summary

We propose a flavor-aware authentication framework for DAOS in which the server is configured with an active authentication flavor and the corresponding principal domain is derived implicitly from that flavor. The client learns the required server flavor from server attach information, confirms that the local agent supports that flavor, and requests a DAOS token for that flavor. The agent delegates flavor-specific identity work to the appropriate plugin, normalizes the result into a common token envelope, derives the correct principal domain for that flavor, and signs the envelope. The server validates the envelope, verifies that the flavor and derived domain match server policy, performs any required flavor-specific proof validation, and only then evaluates ACLs.

In the default configuration, the server remains AUTH_SYS and existing clients continue to work. A site can switch to a different flavor such as AUTH_ACCMAN without reformatting storage, and that switch only requires a server policy change.

Configuration and Policy Model

Server Configuration

If the auth section is absent, the server behaves exactly as it does today and uses AUTH_SYS.

Example AUTH_SYS configuration:

auth: flavor: AUTH_SYS

Example AUTH_ACCMAN configuration:

auth: flavor: AUTH_ACCMAN

Each flavor defines its own unique implicit principal domain.

Server policy semantics:

  • auth.flavor selects the one active flavor for the entire DAOS system.

  • The server must reject startup if the configured flavor is unknown or does not have a valid domain mapping.

Agent Configuration

The initial implementation should use a built-in plugin registry rather than arbitrary dynamic module loading (this avoids runtime auditing).

Example agent plugin configuration:

auth_plugins: auth_accman: endpoint: https://accman.example ca_cert: /etc/daos/accman-ca.pem timeout: 5s

Agent policy semantics:

  • The agent may have multiple flavor plugins compiled in or configured locally.

    • Local plugin availability does not override server policy.

  • The agent must reject token requests for flavors it does not support or that are not fully configured.

Protocol and API Summary

Agent Capability Discovery

  • Caller: libdaos through the local DAOS agent.

  • Purpose: Tell a new client which authentication flavors the local agent can satisfy and what credential types they require.

  • Inputs: None.

  • Outputs: Supported authentication flavors and flavor-specific credential requirements.

  • Compatibility behavior: If the RPC is not implemented, a new client assumes local AUTH_SYS support only.

Server Attach Information

The server extends attach information to advertise its required authentication policy.

New attach fields:

  • auth_flavor

  • auth_token_version

Semantics:

  • These fields tell the client which flavor the server requires.

  • If these are absent, a new client assumes the server is AUTH_SYS only.

Flavor-Aware Token Request

  • Caller: libdaos through the local DAOS agent.

  • Inputs: Requested flavor and flavor-specific proof of identity or credential material.

  • Output: A DAOS token in the common token envelope.

  • Failure behavior: Reject if the requested flavor is unsupported locally, does not match the target server policy, or fails flavor-specific credential validation.

Common Token Envelope

All flavors use the same outer token structure. The envelope contains:

  • Envelope version.

  • Authentication flavor.

  • Principal name.

  • Principal domain.

  • Group(s).

  • Timestamp.

  • DAOS agent signature over the full envelope.

Server Validation Path

The server validation path is:

  1. Verify the DAOS agent signature on the common envelope.

  2. Verify envelope version and basic structure.

  3. Verify auth_flavor matches the configured server flavor.

  4. Convert the principal and domain into the existing ACL subject form.

  5. Evaluate ACLs.

The server must reject requests before ACL evaluation if any policy or proof check fails.

Trust Model and Security Invariants

Trust Boundaries

Client to agent:

The client trusts the local agent to create DAOS tokens only for configured and validated flavors, using the implicit domain associated with that flavor.

Agent to backend:

In the current and newly proposed design, the agent trusts the authentication "backend". In the AUTH_SYS, the agent relies on trusted local Unix socket context. For new plugins, the plugin must either use a configured trusted channel to its backend or validate a backend-issued signed assertion before producing DAOS claims.

Client/agent to server:

The server validates the token envelope from the client. The server treats the envelopes signed by the agent, and its own flavor policy configuration as authoritative. In other words, the server does not trust the client but does trust the agent. Transitively, the server also trusts the authentication backend used by the agent.

Security Invariants

  • A token created for one flavor must never be accepted as another flavor.

  • All flavor domains must be unique.

  • Server flavor policy must be enforced before ACL evaluation.

  • No token may be created for an unconfigured or unhealthy plugin.

Failure Posture

The system fails closed:

  • Unknown flavor means reject.

  • Missing plugin means reject.

  • Proof validation failure means reject.

  • Policy mismatch means reject.

Wire Protocol Changes

  • Extend attach information with auth_flavor and auth_token_version.

  • Add an agent capability discovery RPC.

  • Extend the token request path to carry requested flavor, and flavor-specific credential material.

  • Keep unknown fields ignorable so old components remain compatible when the server stays on AUTH_SYS.

Future Work

  • Additional flavors such as AUTH_GSS.

  • Admin-extensible plugin packaging and certification.

 

Comments