ORCA Credentials Vault

Overview

As using plain text to define and reference sensitive credentials poses a very high security risk, Bluefin has introduced a new capability to ShieldConex ORCA so that the merchant can now avoid hardcoding their sensitive credentials into ORCA configurations.

ShieldConex Orchestration now offers a Credential Vault option that lets you securely manage and rotate credentials used within ShieldConex Orchestrations—without requiring code changes or redeployments.

By referencing credentials dynamically at runtime, customers can keep sensitive keys protected while making configuration updates faster and safer.

📘

ORCA Configuration Authorization

For more details on ORCA authorization, refer to ShieldConex ORCA | Proxy Authorization vs Action Authorization.

Key Features

Key features of Credential Vault enable:

• Secure storage of key/value pairs (HMAC keys, JWT secrets, etc.) that can be referenced at runtime via configuration fields.

• Multiple merchants to use the same orchestration configuration with different credentials.

• Credentials to be rotated or updated without re-publishing or modifying configurations.

• Centralized management and visibility into credential usage.

• Role-based access control for managing secrets at the Partner or Sub-Partner level.

  • Key names must be unique at the partner level. For the comprehensive breakdown of Bluefin User Roles, check out Hierarchy of Organizations.

• This is beneficial in many ways: from eliminating the need to rotate your credentials, to providing the maximum security with your credentials encrypted at rest and only used at runtime when needed.

Access Level

This feature is strictly available to System Admin, System User, and Parner Supervisor user roles as shown in the following table:

🚧

Note

All other user roles cannot access this feature.

Viewing and Managing Secrets

By going to Manage -> Credential Vault, the user can manage their credentials under their respective partner.

Creating a Secret

By clicking on Create Item, the user is prompted the form to input the secret/credential name with its secret value.

🚧

Note

In order to reference a credential from an ORCA configuration, both the ORCA configuration and the credential must be created under the same partner.

🚧

Permanent Key Name

Once the user creates a new credential, the value can be changed but the key name is immutable and permanent. The only workaround involves deleting the existing key credential and adding a new one under the new name.

Key names must be unique at the partner level.

Editing a Secret

The user has the ability to edit an existing secret, modifying its secret value.

Referencing a Secret

Finally, the user is all set to reference and use their credential vault value in an ORCA configuration.

This example showcases both Decryptx action and proxy target destination referencing secrets via authorization.

{
  "proxy": {
    "method": "post",
    "target": "{The target URL/IP Address}",
    "authorization": {
      "type": "hmac",
      "username": "my-proxy-username",
      "secret": "{{my-proxy-auth}}"
    }
  },
  "actions": [
    {
      "logSettings": {
        "requestMasks": [
          {
            "transformationSource": "body",
            "transformationType": "jsonpath",
            "transformationPath": "$.deviceSerial",
            "pattern": "all"
          }
        ],
        "responseMasks": [
          {
            "transformationSource": "body",
            "transformationType": "jsonpath",
            "transformationPath": "$.messageId",
            "pattern": "all"
          }
        ]
      },
      "type": "parser",
      "authorization": {
        "type": "basic",
        "username": "payconex-qsapi",
        "password": "{{decryptx-secret}}"
      },
      "serialLocation": {
        "transformationSource": "body",
        "transformationType": "jsonpath",
        "transformationPath": "$.Device.Serial"
      },
      "instructions": [
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Track1",
          "instructionType": "substitution",
          "format": "track1",
          "dataType": "string",
          "default": "mydefault"
        },
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Track2",
          "instructionType": "substitution",
          "format": "track2",
          "dataType": "string",
          "default": "mydefault"
        },
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.PAN",
          "instructionType": "substitution",
          "format": "pan",
          "dataType": "string",
          "default": "mydefault"
        },
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.Expiry",
          "instructionType": "substitution",
          "format": "expiry",
          "dataType": "string",
          "default": "mydefault"
        },
        {
          "transformationSource": "body",
          "transformationType": "jsonpath",
          "transformationPath": "$.Card.CVV",
          "instructionType": "substitution",
          "format": "cvv",
          "dataType": "string",
          "default": "mydefault"
        }
      ]
    }
  ],
  "detailedAuditEndDate": "2026-01-19T20:05:54.295Z"
}

🚧

Note

In order to reference a credential from an ORCA configuration, both the ORCA configuration and the credential must be created under the same partner.

Deleting a Secret

The user has the ability to delete a secret, permanently removing it from the Credential Vault.

This action cannot be undone.

📘

Caution

If the merchant is removing a secret from the vault, it is generally the best practice to recreate the same secret under the same name to prevent breaking all of the existing integrations unless the merchant is moving away from the respective key name altogether.

Visa HMAC-based Proxy Authentication Use Case

One of the most significant use cases of ORCA Credential Vault is Visa HMAC-based Proxy Authentication.

ShieldConex ORCA adds the capability of authorizing requests to the Cybersource REST API (which connects to the VPC Gateway), enabling secure communication with Visa APIs.

For this use case, merchants are required to use the Credential Vault to securely manage Visa secret keys.

The Credential Vault is also required for referencing all other sensitive credentials, including ShieldConex or Decryptx actions and Target Destination/Payment Processor authorization.

Also see References | Proxy Authorization and References | Actions Authorization.