Application authentication methods

The Credential Providers facilitates multiple methods to authenticate applications. These methods are based on registering information in the Vault with the unique application ID.

Supported authentication methods

Method

Credential
Provider

Central
Credential
Provider

Credential
Provider
for Mac

Credential
Provider
for z/OS

Allowed machines

P

P

P

P

OS user

P

P

P

P

Path

P

O

O

O

Hash

P

O

O

O

Client certificates

O

P

O

O

 

Using an application with no authentication method configured is not recommended in any scenario.

Best practice is to configure all methods for each application; this enforces more restricted access to secrets stored in the Vault.

These authentication methods can be specified for the application ID:

 

You cannot configure both OS User and Client Certificates authentication simultaneously on the Central Credential Provider. To configure multiple authentication methods on the same Central Credential Provider, see Multiple security configurations and authentication methods for the Central Credential Provider web service.

Allowed machines authentication

The list of allowed machines (based on IP/DNS/Hostname/IP subnet in CIDR IPv4 format) that are specified for the application ID in the Vault. Multiple addresses can be specified for a single application ID, which enables multiple instances of a single application to run on different machines and use the same application ID. All the specified addresses are verified each time a request is received from the application.

The Credential Provider address is written in the local audit log of the Credential Provider when it starts.

 
  • When authenticating applications in environments where the IP is prone to frequent changes, such as cloud environments, e.g., AWS, specify the machine’s hostname or an IP subnet, and not a single IP.
  • In Central Credential Provider, hostname is not supported for Allowed machines.

OS user authentication

The OS users under which the application runs. Credential Provider compares the name of the OS user running the requesting application process with the OS user name that is specified for the application ID in the Vault. Multiple OS users can be specified for a single application ID. All the specified OS users are verified each time a request is received from the application.

 

 

Credential Provider for Windows / Central Credential Provider

In a Windows environment, when the Windows domain OS username is specified in the Password SDK, it must be preceded by the domain name. For example, MYCOMPANY_DOM\username.

In Central Credential Provider, OS users are authenticated using Window domain authentication. For details on setting this up, see Authentication method configurations on the Central Credential Provider

In addition, if Central Credential Provider is installed on the same server as a hardened PVWA, you must also configure your server to accept OS user authentication. For details, see Authentication method configurations on the Central Credential Provider.

Credential Provider for Solaris/Linux/AIX When setuid is defined on an application binary, Credential Provider authenticates the elevated user and not the user that ran the application binary.

Application path authentication

The list of valid paths for the application. The Credential Provider compares the full path of the application or script file with the path specified for the application ID in the Vault, by verifying either an exact file path or all the applications/scripts in a specific folder. For details, see to Application path authentication.

 
  • In a UNIX Credential Provider environment, this authentication option is case-sensitive. In a Windows Credential Provider environment, this authentication option is not case-sensitive, and the path delimiter can be specified as either ‘/’ or ‘\’.
  • When using the .NET SDK from PowerShell scripts, path authentication is not supported.

Application hash authentication

The list of valid hash values of the application. The Credential Provider calculates the calling application hash value and compares it with the hash values specified for the application ID in the Vault. The main benefit of authenticating an application based on its hash is to protect it from any malicious code changes. For more information, refer to Authenticate with a hash value.

 

When using the .NET SDK from PowerShell scripts, hash authentication is not supported.

Client certificates authentication

A signed certificate that enables client side authentication of the requesting application against the Central Credential Provider web service.

The following client certificate authentications are supported:

Authentication Description
Certificate Serial Number

Uses the serial number of the certificate to authenticate the application.

Extract the Serial Number value from the Client Certificate.

The following example shows how to extract the Serial Number in Windows Certificate Manager, although any management utility can be used.

 
  • The certificate must be trusted by IIS.

  • Ensure that no duplicate certificates are issued.

  • Ensure that the Serial Number contains only the valid characters accepted for Serial Number authentication – [a-f], [A-F], [0-9] and ‘#’

Certificate Attribute

Uses the SubjectAlternativeName, Subject, or Issuer attribute to authenticate the application

 
  • Applications can authenticate with either a self-signed certificate or a certificate signed by a Certificate Authority (CA). For more information, refer to Central Credential Provider web service configuration.
  • Certificate Attribute authentication is configurable through the REST API only.
  • Certificate attribute authentication: SubjectAlternativeName must be one of the following: : "DNS Name"/ "IP Address"/ "URI" / "RFC822"

Change the default location of the SDK folder

UNIX/Linux

In UNIX/Linux implementations, for all authentication types, the application’s OS user must have write permissions in the /tmp folder. If this does not conform to your enterprise policy standards, an alternative Temp folder can be specified in the AIM_TEMP_FOLDER environment variable. This folder must be available to the application as well as to the Credential Provider.

To specify an alternative folder, in aimprv, under the start section, add export AIM_TEMP_FOLDER=<folder_path>. If you do specify an alternative folder, the application requires write and execute permissions on the folder. The Credential Provider has these permissions by default because it runs under root.

After changing this environment variable, restart the Credential Provider.

Windows

For Windows implementations, for all authentication types, the application’s OS user must have read permissions to AIM_TEMP_FOLDER, which, by default, is set to the SDK folder. If this does not conform to your enterprise policy standards, an alternative folder can be specified in the AIM_TEMP_FOLDER environment variable.

The alternative folder must be available to the application as well as to the Credential Provider with read permissions to all users and write and execute permissions to administrative/root users only.

After changing this environment variable, restart the Credential Provider.