cf68529c-d46b-4e20-88eb-db46d057f16f.png

Integrations Manager

**THE PROBLEM TO BE SOLVED**

  

Certificate-based, multi-factor authentication is a mainstay security technique used by the U.S. Federal Government to ensure the identities of entities within a Public Key Infrastructure (PKI).  Two primary components of multi-factor authentication are “what you have” and “what you know.” The “what you have” in a PKI consists of a securely stored private key and an associated digital certificate that are the unique user credentials identifying the entity. The “what you know” is a password to unlock access to the securely-stored credentials.

  

When the entity in need of a certified identity is a person, secure storage and distribution of the user credentials is often easily facilitated by utilizing existing technology, such as a secure smart card or USB token.  The person assumes physical ownership and responsibility of the token and can use it as needed to access PK-enabled resources.  But what if the entity in need of credentials is a non-person entity (NPE), like a device, software robot or some other automation technology?  These entities still must have hardware-secured credentials to meet security mandates.  Or what if the entity is indeed a person, but token use is not desirable or not an option?    
  
With this in mind, any or all of the following issues may present roadblocks to the use of a multi-factor token for all users in a PKI:

*   Policy may dictate that a token cannot be issued to a non-person entity
*   The physical security of a token issued to a non-person entity presents a cumbersome, inefficient, or impossible requirement to meet
*   Virtual machines are being used which can’t access physical tokens
*   Multiple physical machines require access to the credentials on a single token
*   Hardware-based, multi-factor authentication is needed for human users, but token use is either not feasible or undesirable

  

**LUNA CREDENTIAL SYSTEM**

  

The Luna Credential System (LCS) introduces a new, patent pending,  approach to multi-factor authentication by maintaining user credentials in a centralized hardware device that is securely accessible by endpoints in a distributed network.  It unites the familiarity of certificate-based authentication with the security of a FIPS 140-2 certified hardware security module (HSM).  LCS is a multi-purpose, secure credential system ideally suited for an environment in which the UiPath Robot endpoints cannot use a traditional small form-factor token. Composed of the Luna Credential HSM and the Luna Credential Client, LCS supports a number of use cases with UiPath Orchestrator and Robot, including authentication to PK-enabled applications and websites, Windows Logon, and HSM-secured Credential Stores.

  

### LUNA CREDENTIAL HSM

Derived from TCT’s flagship Luna Network HSM, the Luna Credential HSM generates and protects PKI user credentials within the HSM thereby replacing individual tokens. Credentials never leave the security boundary of the HSM and can only be accessed by authorized endpoints over a secure communication link. The Luna Credential HSM provides a scalable architecture and supports multiple independent “credential bins.”  A credential bin is a cryptographically isolated location within the HSM that contains  the private key and associated certificate for individual entities.   These identity credentials can only be accessed by endpoints when the correct password for the credential bin is provided.  An internal credential directory is maintained by the Luna Credential HSM to correspond bins with entities that access the bins via the Luna Credential Client.

  

### LUNA CREDENTIAL CLIENT

The Luna Credential Client, which is installed on the endpoint machine, provides an equivalent user experience to traditional multi-factor authentication login.  During any operation that needs the entity’s certificate and corresponding private key, the Luna Credential Client establishes secure communications to the HSM. Utilizing the credential directory onboard the HSM, the client determines the correct credential bin for the given entity and sends the password to the HSM. Once the password is validated, the process on the endpoint system can proceed to utilize the keys and certificates within the entity’s specific credential bin.  This password may be entered by a human user, or in the case of a NPE, may be supplied by an automated process.

  

The Luna Credential Client includes a Windows credential provider component that prompts the user for their credential bin password and proceeds to complete the standard Windows Logon using identity credentials residing in the credential HSM. By hooking into the natural authentication flow of Windows systems, the user experience is no different from what users are accustomed to. Additionally, the Luna Credential Client includes an API to allow technology partners with their own credential providers or automated Windows Logon processes to make use of the Luna Credential System.

Luna Credential System seamlessly integrates with Orchestrator and Robots to provide a highly secure RPA solution that meets the multi-factor authentication requirements of the U.S. Federal Government

bd476b78-56e1-4a82-b14a-a6651e033040.jpg

**PROBLEM TO BE SOLVED**

  

Certificate-based, multi-factor authentication is a mainstay security technique used by the U.S. Federal Government to ensure the identities of entities within a Public Key Infrastructure (PKI).  Two primary components of multi-factor authentication are “what you have” and “what you know.” The “what you have” in a PKI consists of a securely stored private key and an associated digital certificate that are the unique user credentials identifying the entity. The “what you know” is a password to unlock access to the securely-stored credentials.

  

When the entity in need of a certified identity is a person, secure storage and distribution of the user credentials is often easily facilitated by utilizing existing technology, such as a secure smart card or USB token.  The person assumes physical ownership and responsibility of the token and can use it as needed to access PK-enabled resources.  But what if the entity in need of credentials is a non-person entity (NPE), like a device, software robot or some other automation technology?  These entities still must have hardware-secured credentials to meet security mandates.  Or what if the entity is indeed a person, but token use is not desirable or not an option?    
  
With this in mind, any or all of the following issues may present roadblocks to the use of a multi-factor token for all users in a PKI:

*   Policy may dictate that a token cannot be issued to a non-person entity
*   The physical security of a token issued to a non-person entity presents a cumbersome, inefficient, or impossible requirement to meet
*   Virtual machines are being used which can’t access physical tokens
*   Multiple physical machines require access to the credentials on a single token
*   Hardware-based, multi-factor authentication is needed for human users, but token use is either not feasible or undesirable

  

**LUNA CREDENTIAL SYSTEM**

  

The Luna Credential System (LCS) introduces a new, patent pending,  approach to multi-factor authentication by maintaining user credentials in a centralized hardware device that is securely accessible by endpoints in a distributed network.  It unites the familiarity of certificate-based authentication with the security of a FIPS 140-2 certified hardware security module (HSM).  LCS is a multi-purpose, secure credential system ideally suited for an environment in which the UiPath Robot endpoints cannot use a traditional small form-factor token. Composed of the Luna Credential HSM and the Luna Credential Client, LCS supports a number of use cases with UiPath Orchestrator and Robot, including authentication to PK-enabled applications and websites, Windows Logon, and HSM-secured Credential Stores.

  

### LUNA CREDENTIAL HSM

Derived from TCT’s flagship Luna Network HSM, the Luna Credential HSM generates and protects PKI user credentials within the HSM thereby replacing individual tokens. Credentials never leave the security boundary of the HSM and can only be accessed by authorized endpoints over a secure communication link. The Luna Credential HSM provides a scalable architecture and supports multiple independent “credential bins.”  A credential bin is a cryptographically isolated location within the HSM that contains  the private key and associated certificate for individual entities.   These identity credentials can only be accessed by endpoints when the correct password for the credential bin is provided.  An internal credential directory is maintained by the Luna Credential HSM to correspond bins with entities that access the bins via the Luna Credential Client.

  

### LUNA CREDENTIAL CLIENT

The Luna Credential Client, which is installed on the endpoint machine, provides an equivalent user experience to traditional multi-factor authentication login.  During any operation that needs the entity’s certificate and corresponding private key, the Luna Credential Client establishes secure communications to the HSM. Utilizing the credential directory onboard the HSM, the client determines the correct credential bin for the given entity and sends the password to the HSM. Once the password is validated, the process on the endpoint system can proceed to utilize the keys and certificates within the entity’s specific credential bin.  This password may be entered by a human user, or in the case of a NPE, may be supplied by an automated process.

  

The Luna Credential Client includes a Windows credential provider component that prompts the user for their credential bin password and proceeds to complete the standard Windows Logon using identity credentials residing in the credential HSM. By hooking into the natural authentication flow of Windows systems, the user experience is no different from what users are accustomed to. Additionally, the Luna Credential Client includes an API to allow technology partners with their own credential providers or automated Windows Logon processes to make use of the Luna Credential System.

**THE PROBLEM TO BE SOLVED**

  

UiPath Orchestrator stores Robot login credentials and workflow process Assets in a Credential Store that by default uses Orchestrator’s internal software database for storage. By utilizing the Luna Vault feature of Thales TCT’s Luna Credential System (LCS), this highly sensitive data can be stored in a FIPS 140-2 Level 3 hardware security module (HSM) providing optimal security.

  

**HOW IT WORKS** 

  

Orchestrator enables the creation of Credential Stores using other storage medium by virtue of loading library plugins. By loading the LCS Luna Vault Plugin, LCS implementers can direct the Credential Store to use the highly secure Luna Credential HSM as its default storage location. With the inherent access control mechanisms implemented by LCS, only the Orchestrator machine can access the data stored within the HSM. In High-Density Robot environments, where Windows Remote Desktop is used, Luna Vault can provide HSM storage for the Robots’ login credentials, thus providing highly secure, hardware-based protection.

  

**THE LUNA CREDENTIAL SYSTEM**

  

Luna Vault is an optional feature of the core Luna Credential System that also enables UiPath’s RPA to utilize the HSM for Public Key Infrastructure (PKI) multi-factor authentication using Windows Logon. In this use case, the HSM replaces smart cards as the hardware storage mechanism for PKI credentials, thus enabling Unattended Robots to meet the multi-factor authentication requirements of the U.S. Federal Government. (Read more about this use case solution here: https://marketplace.uipath.com/listings/3012 ). As an optional feature that can be enabled in this environment, Luna Vault can also provide hardware protection of the Robots' credential password and workflow process Assets in addition to the PKI credentials.

  

The Luna Credential System for the Luna Vault use case is comprised of the following: 

*   The Luna Credential HSM - a FIPS 140-2 Level 3 validated hardware security module built exclusively for the U.S. Federal Government
*   The Luna Credential Client - software installed on the Orchestrator machine to establish and highly secure connection with the HSM

Thales TCT’s Luna Vault feature of the Luna Credential System provides FIPS-validated, hardware-based storage for the sensitive data in an Orchestrator Credential Store.

fde3a2f7-2c9f-496f-8ed7-b6883895ad0f.jpg

**THE PROBLEM TO BE SOLVED**

  

UiPath Orchestrator stores Robot login credentials and workflow process Assets in a Credential Store that by default uses Orchestrator’s internal software database for storage. By utilizing the Luna Vault feature of Thales TCT’s Luna Credential System (LCS), this highly sensitive data can be stored in a FIPS 140-2 Level 3 hardware security module (HSM) providing optimal security.

  

**HOW IT WORKS** 

  

Orchestrator enables the creation of Credential Stores using other storage medium by virtue of loading library plugins. By loading the LCS Luna Vault Plugin, LCS implementers can direct the Credential Store to use the highly secure Luna Credential HSM as its default storage location. With the inherent access control mechanisms implemented by LCS, only the Orchestrator machine can access the data stored within the HSM. In High-Density Robot environments, where Windows Remote Desktop is used, Luna Vault can provide HSM storage for the Robots’ login credentials, thus providing highly secure, hardware-based protection.

  

**THE LUNA CREDENTIAL SYSTEM**

  

Luna Vault is an optional feature of the core Luna Credential System that also enables UiPath’s RPA to utilize the HSM for Public Key Infrastructure (PKI) multi-factor authentication using Windows Logon. In this use case, the HSM replaces smart cards as the hardware storage mechanism for PKI credentials, thus enabling Unattended Robots to meet the multi-factor authentication requirements of the U.S. Federal Government.  As an optional feature that can be enabled in this environment, Luna Vault can also provide hardware protection of the Robots' credential password and workflow process Assets in addition to the PKI credentials.

  

The Luna Credential System for the Luna Vault is comprised of the following LCS components: 

*   The Luna Credential HSM - a FIPS 140-2 Level 3 validated hardware security module built exclusively for the U.S. Federal Government
*   The Luna Credential Client - software installed on the Orchestrator machine to establish a highly secure connection with the HSM