White Papers

Introduction to Delegated Authorization
Delegated Authorization is a way to access REST APIs in a modern secure
manner. It is an important concept in modern HTTP APIs, with one of the most
popular implementations being the IETF standard for OAuth 2.0 (RFC 6749).
OAuth 2.0 is an industry-standard for handling web-based authorization and
offers excellent solutions to get HTTP services to interoperate in an elegant and
secure way.
Delegated auth does away with providing a username and password for every
device. Instead users can log into a centralized “Authorization server” and get
issued a “token”. These tokens can then be used on configured systems instead
of a username and password. There are several Enterprise level authorization
servers including Ping Identity, Microsoft ADFS, and open source solutions such
as Keycloak. These authorization servers allow a wide variety of authentication
services including AD and LDAP to suit consumers’ various needs.
Since Delegated Authorization does not involve sharing usernames or passwords
with clients, it provides enhanced security and remains unaffected by password
rotation schemes. This simplifies password rotation policies since new
passwords do not need to be “rolled out” to scripts or console applications.
Limitations with the legacy architecture
With previous iDRAC releases, the only way to access iDRAC REST APIs was to
include a username and password as authentication for every HTTP request.
Optionally a username and password could be used to create a session, but the
initial credentials exchange was still required.
This is true for both iDRAC local user accounts as well as for directory services
such as Active Directory and LDAP. In both cases, the iDRAC must either handle
user credentials to perform authentication for local users, or handle AD/LDAP
user credentials to be passed over to AD/LDAP servers for authentication.
In a datacenter environment, scripts and console applications handle the remote
server management. Since usernames and passwords are required for all
iDRAC REST APIs, these scripts and applications need a username and
password to operate.
It is apparent that the legacy solution is not very secure and is fraught with
maintenance and scalability issues, some of which are outlined below.
Security
1. A security breach may result in denial-of-service attacks and loss of
sensitive customer data such as usernames and passwords.
2. The legacy back-end applications need to deal with user credentials for
storage, retrieval, and updates in a database.
3. User credentials may need to be transmitted over the network for
AD/LDAP configurations.
4. Inadvertent leakage of sensitive user information in troubleshooting logs
on proxies and servers etc.
5. Password rotation policies mandate client scripts and applications to be
updated on a periodic basis.
Maintenance/Scalability
1. User account creation and management.
2. iDRAC provides an array of fine-grained user privileges but not all of
them can be leveraged due to the limited number of local user
accounts that can be set up on the iDRAC.
3. In the scenario where there are multiple iDRAC’s to be configured, all
the user creation and management tasks need to be performed on a
per-iDRAC basis.