Application path authentication

This topic describes how to use the application authentication method for supported SDKs.

 

PowerShell script path authentication is not supported if the path contains spaces.

Java Password SDK

When authenticating with the application path in the Java Password SDK, the Credential Provider verifies the path of the classes in the calling stack as follows:

Type

Path

A Java class packed in a JAR file

The path of the class is taken as the path of the JAR file itself. For example: /Machine1/Apps/App1.jar.

A Java class not packed in a JAR file

The path of the class is taken. For example: /Machine1/Apps/App1Main.class.

At least one of these values (from the call stack) must be registered in the Vault as an allowed path for the calling application. The characteristics of the path specified in the application ID in the Vault define how the path will be verified:

Property

Path

Allow internal scripts to request credentials

If a path value is defined with this property, the calling class/JAR (as well as parent classes/JARs in the stack) is validated. This is useful when using a wrapper around the Password SDK to ensure that the path of the classes calling the wrapper is verified and not the wrapper itself.

Path is Folder

The Credential Provider verifies the calling class/JAR (or parent classes/JARs) that resides in the specified folder or under one of its subfolders.

Application server environment

The methods described above are also relevant for Java Application Servers, meaning that users must register the path of classes/JARs within WAR/EAR files.

This section describes some of the behaviors that are unique to these environments and should be considered when deploying applications using the Credential Provider path authentication.

When deploying a WAR/EAR file, some Application Servers unpack the application file to a temporary path that changes after each deployment or that manipulate the classes/JARs within the WAR/EAR. For example:

Server

Path

JBoss

WAR/EAR files are deployed to a temporary path that changes every deployment, making registered path values in the Vault invalid after redeploying. In order to avoid this and still benefit from path authentication, EAR/WAR files must be deployed in an exploded way (including WAR files within EAR files). This way, registered path values stay valid even after redeployment.

WebLogic

WAR/EAR files are always deployed to the same location, thus, the path of the relevant classes/JAR files after deployment can be registered in the Vault. Even when deploying an exploded EAR/WAR file, WebLogic deploys JAR files within them to a different location, but it is always the same one, even after redeployment. On the other hand, class files of an exploded EAR/WAR file are not moved.
 

When deploying an EAR/WAR file, WebLogic creates a JAR file called _wl_cls_gen.jar from all the classes that reside under the web-in/classes" directory. To authenticate any of these class files, register the full name of the class using an “!” (exclamation mark) between the JAR and the class names. For example: a valid path for class com.billing.Initialization, which resides in web-inf/classes, could be:

E:/Oracle/Middleware/user_projects/domains/base_domain/servers/
AdminServer/tmp/_WL_user/EarBillingInitClassLoaderEnterprise/
2n4n54/war/WEB-INF/lib/_wl_cls_gen.jar!/com/test/UnderTest.class

Other application servers that are not mentioned above (Tomcat, WebSphere) allow deploying to a specific path or do not perform any manipulations on the unpacked files.

Application Server Credential Providers

In addition to the behavior described above, any class/JAR file that is registered for path authentication must have the Allow internal scripts to request credentials property.

 

Paths of classes generated from JSP files cannot be authenticated.

CLI Password SDK

When authenticating with the application path in the CLI Password SDK, the Credential Provider compares the path of the script file. As hierarchies of scripts can call each other, the path specified in the application ID in the Vault must define how the script path will be verified:

Allow internal scripts to request credentials

If a path value is defined with this property, the calling script as well as the parent script will be validated. This allows users to define the path of a master script, while calling the SDK directly from it or from a subscript called by the master script. This is useful when using a wrapper around the Password SDK. For example, if Script A calls Script B, which in turn calls the CLI (Script B is a wrapper to the SDK), Script B is always be validated, but Script A must be marked with this property to be validated.

If a UNIX script calls the SDK from an inner script (e.g. wrapper code), and the inner script is called using the “import” method (i.e. “./scriptname”), an internal process is not created for the inner script, and the parent script path must be registered.

Path is Folder

The Credential Provider verifies the calling script (or the parent script) that resides in the specified folder or under one of its subfolders.

Script calling method

Scripts that will be validated must be called in one of the following ways:

Description

Example

A command line that includes the script engine name as well as the script name itself.

For example: bash /home/myscript.

The first line in the script file must specify the script engine.

For example: #!/bin/bash.

In addition, the script file name must be specified as a full path (not a relative path). Currently, the Credential Provider only investigates the first two levels of any script hierarchy (the calling process and its parent process).

Calling the CLI Password SDK from Perl scripts

When using the CLI Password SDK in Perl scripts, use the following guidelines:

The SDK must be called using backticks, as shown in the following example:

      
    $result=`CLIPasswordSDK.exe GetPassword /p AppDescs.AppID=AppBilling /p Query=”Safe=PasswordSafe;Folder=Root;Object=Application1” /o Password  2>&1`;

  • If you use a general wrapper around the SDK, and want to authenticate the code that is calling the wrapper, the wrapper should be called using the ‘do’ command, e.g. “do CyberArkGetPasswordWrapper.pl’.

    • When registering the valid path for the application in the Vault, always use the Allow internal scripts to request credential on behalf of this application ID option.

The following example shows how to call a script in Windows so that the Credential Provider can successfully identify it:

  
cmd /c c:\MyScripts\scriptname.cmd

The following example shows how to call a script in UNIX so that the Credential Provider can successfully identify it:

  
bash /home/scripts/scriptname.sh

 

 

When scripts are run and authenticated using the CLI Password SDK via a non-standard shell, the TrustedCLIShells parameter must be configured in the main configuration file. For more information, see Restrict trusted shells to run the CLI password SDK.

C/C++ Password SDK

When authenticating with the application path in the C/C++ Password SDK, the Credential Provider compares the path of the calling executable to the registered application paths.

Path Description
Allow internal scripts to request credentials

Cannot be used for this SDK. Independently. If the SDK is called directly from the executable or from an so/dll, the Credential Provider checks the path of the main executable that matches the registered application path.
Path is Folder

The Credential Provider verifies the calling executable that resides in the specified folder or under one of its subfolders.

.NET Password SDK

When authenticating with the application path in the .NET Password SDK, the Credential Provider verifies the path of the assemblies in the calling stack. At least one of these values must be registered in the Vault as an allowed path for the calling application. The characteristics of the path specified in the application ID in the Vault define how the path will be verified:

  • Allow internal scripts to request credentials – If a path value is defined with this property, the calling assembly (as well as parent assemblies in the stack) is validated. This is useful when using a wrapper around the Password SDK to ensure the path of the assemblies calling the wrapper is verified and not the wrapper itself.

     

    If you are using .NET Reflection, this option must be selected in the Add Path Authentication window when you specify the path in the PVWA. For more information, refer to Add applications.

  • Path is Folder – The Credential Provider verifies the calling assembly (or parent assemblies) that resides in the specified folder or under one of its subfolders.

  • Shared folder support - For more information, see Shared folders support