Skip to main content

Eliminate Embedded Passwords - Hitachi ID Privileged Access Manager

Hitachi ID Privileged Access Manager includes an API that enables applications to disclose passwords and eliminates the storage of static, plaintext passwords. Privileged Access Manager periodically randomizes service passwords, while applications use the API to retrieve passwords as/when required.

The Privileged Access Manager API is accessed using SOAP over HTTPS.

For example, Privileged Access Manager may randomize an Oracle DBMS login password every 24 hours. Web applications which use the password to establish database connections can periodically sign into Privileged Access Manager with their own credentials (see below) and retrieve the current Oracle login password.

An important design consideration when implementing a privileged password retrieval API is how the client which requests password disclosure (the web application in the above example) authenticates itself to the API service. Privileged Access Manager secures this process with a combination of ACLs, one-time passwords and IP subnets:

  1. API clients have their own IDs, used to sign into Privileged Access Manager.
  2. These IDs are attached to console user groups and assigned ACLs, allowing them to disclose some passwords but not others.
  3. API client login IDs are assigned one-time passwords (OTPs). In effect, the password used by the client software to sign into the Privileged Access Manager API changes to a new, random string on each API connection.
  4. API client login IDs are bound to IP subnets. An API client can only sign into the API service from a given IP range.

Wrapper code is provided for the SOAP API for a variety of platforms / programming languages, such as .NET, Java, Linux/C, etc. This wrapper code manages several functions:

  1. Storing the one time password (OTP) used to authenticate to the API.
  2. Serializing access to the API, to support use of the OTP.
  3. Keeping cached copies of passwords previously retrieved from the API, along with data about how long to retain those copies and how long they should be assumed to be valid. This makes the system more performant (due to less frequent API calls) and more reliable (continued operation even if the API is temporarily unavailable).
  4. Encrypting the above, sensitive data so that it's not visible -- even to locally privileged users.

Encryption of the OTP and of cached passwords implies an encryption key. The API wrappers support a variety of methods to produce this key, including:

  1. A static key (e.g., embedded into the application or configuration file) -- useful during development or debugging.
  2. A key generated from characteristics of the machine on which the application runs, such as its MAC addresses, IP addresses, hostname, etc.
  3. A key generated from characteristics of the program which is calling the API (i.e., a cryptographic hash of the program itself).

Hitachi ID Systems is happy to add platform bindings for this wrapper code based on customer demand (i.e., we add support for the programming language and runtime that customers need as required, and usually at no additional cost).

This wrapper is also provided in command-line form, suitable for retrieving passwords efficiently and securely from Privileged Access Manager (with local, encrypted caching) and injecting those passwords on the command-line, into configuration files or into the input of scripts.

page top page top