1. Remote Administration Daemon Client User's Guide
  2. REST APIs for RAD Clients
  3. RAD Authentication

RAD Authentication

With RAD, all communications between client and server are encapsulated within a connection. When a connection closes, all state associated with the connection is reclaimed by the RAD daemon. However, because RESTful interactions that happen over HTTP are stateless, a client must establish a connection and authenticate each request.

RAD authentication is performed using the authentication module API. This module has some special features, but in general one interacts with it much as with any other module. Oracle Solaris 11.4 delivers two major, incompatible authentication module versions.

RAD Authentication Module Version 1.0

Authenticates the client in one request where the client provides both username and password.

This version assumes that the server-side PAM configuration only ever requires a username and password. Use this version if that is a safe assumption, or if the same RAD client needs to interoperate with Oracle Solaris 11.3 and earlier releases.

RAD Authentication Module Version 2.0

Authenticates the client in multiple request-responses, thus fully exposing the underlying PAM conversation

Where the server-side PAM configuration may prompt the user for multiple credentials, such as OTP or RADIUS requests, you must use this version. You should use the authentication module version 2.0 API when the client is an interactive application rather than scripted automation. The Oracle Solaris WebUI SMF service uses the authentication module version 2.0 API.

Instead of having to re-authenticate for every request, RAD provides a token. When a client connects to RAD and successfully authenticates, RAD generates a unique token for the client and then services the request. At the same time, RAD stores the token and details about the client connection. On subsequent requests, if a token is supplied, RAD uses the token to retrieve the previously authenticated connection, associates it with the incoming request, and processes the request.

Because a token is generated when a client connects to RAD for the first time, the token is absent from the request. Tokens have the following characteristics:

  • Tokens are a 256-bit opaque value constructed from a random number, which provides security and minimizes the likelihood of collisions.

  • Tokens have a finite, configurable lifetime of up to a maximum of 24 hours. The default lifetime is 1 hour. The lifetime is configured as part of the initial authentication request. The expiry time of the token is reset or extended whenever an authenticated request is received.

  • If the token received in a request is invalid or has expired, an error is returned and the client must re-authenticate.

  • If the RAD slave is killed or if RAD is terminated, all tokens and their corresponding sessions are destroyed.