White Papers

4. Maintain and enhance authentication modules to comply with the latest
security standards through application of patches etc.
Key terms for Delegated Authorization
Starting iDRAC version 4.20.20.00, iDRAC introduces support for Delegated
Authorization.
To configure iDRAC for Delegated Authorization, an iDRAC admin needs to
understand certain key OAuth 2.0 terminology. Initially, this terminology can be
difficult to grasp. To simplify things, this section briefly describes various key
OAuth 2.0 terms from an iDRAC perspective. In the next section, we will use
these terms in describing the basic workflow.
Client
A client is a third-party application, console, or script that accesses the iDRAC
REST APIs with the user’s consent.
Authorization Server
The Authorization Server is the only device that directly handles usernames and
passwords. It issues tokens to the client after successful user authentication.
Resource Server
The iDRAC is the Resource Server.
Resource Owner
The User is the Resource Owner.
Token
Tokens are used by iDRAC in place of usernames and passwords.
Offline Tokens
Tokens that Users provide to applications or scripts that can be used without
requesting consent from the User each time.
Solution Overview
To address limitations with the legacy architecture, it becomes imperative to
move to a centralized authorization solution and delegate authorization
responsibilities to specialized servers. These authorization servers are
specifically designed to provide user identity and access management solutions.
From an iDRAC perspective, the notion of Delegated Authorization is that a script
or console application (“Client”) can, on behalf of a user (“Resource Owner”),
obtain authorization from an "Authorization Server" in the form of a "token". This
token is then presented in a designated HTTP request header as part of API
accesses to the iDRAC (“Resource Server”). The token contains details about
the Authorization Server issuing the token, the iDRAC that this token is valid for,
and user details such as the username and privileges that the user should have
on the iDRAC.
Most importantly, the tokens are secure and trustworthy as they are signed by
the Authorization Server’s private encryption key. The public key is known to the
iDRAC and is therefore used to verify the authenticity of the tokens.