First transform

Time to protect data. The example assumes your portal configuration defines a class and property for the field you want to protect, and a rights context that grants Protect to a role.

Make the call

TOKEN=$(curl -s -X POST "$KUSTODYAN_IDENTITY_URL/connect/token" \
  -d grant_type=client_credentials \
  -d client_id="$KUSTODYAN_CLIENT_ID" \
  -d client_secret="$KUSTODYAN_CLIENT_SECRET" | jq -r .access_token)

curl -X POST "$KUSTODYAN_ENGINE_URL/transform" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rightsContexts": [{
      "guid": "11111111-1111-1111-1111-111111111111",
      "evidences": [{ "name": "Role", "value": "<role>" }]
    }],
    "processingContexts": [{
      "guid": "22222222-2222-2222-2222-222222222222",
      "evidences": [{ "name": "Action", "value": "Protect" }]
    }],
    "requests": [{
      "guid": "33333333-3333-3333-3333-333333333333",
      "rightsContext": "11111111-1111-1111-1111-111111111111",
      "processingContext": "22222222-2222-2222-2222-222222222222",
      "instances": [{
        "className": "<class>",
        "propertyName": "<property>",
        "value": "<value>"
      }]
    }]
  }'

The GUIDs above are placeholders you pick. They can be any value, fixed per integration or generated per call, as long as each one is unique within the request and the references match: requests[].rightsContext must equal a rightsContexts[].guid, and requests[].processingContext must equal a processingContexts[].guid.

Read the response

{
  "responses": [{
    "request": "33333333-3333-3333-3333-333333333333",
    "instances": [{
      "className": "<class>",
      "propertyName": "<property>",
      "value": "<value>"
    }]
  }]
}

Store the protected value in place of the original. To unprotect later, send the protected value back through transform with a processingContext that points to your unprotect sequence. See Examples for the sample configuration and which techniques are reversible.

Test from the portal first

Before wiring up your application, the CoreAdmin portal includes a Transform API tester. Pick a configuration, fill in evidence values, and run protect and unprotect cycles to confirm your contexts and transformer sequences behave as expected. This is the fastest way to validate configuration changes before touching code.

Where to integrate

Several integration patterns are possible. As a general security principle, protect data as early as possible and unprotect it as late as possible, so cleartext exists in as few places and for as little time as it can. The patterns below are listed roughly from the earliest point of protection to the latest.

Gateway-based protection: An API gateway (or reverse proxy) in front of your application calls transform on requests and responses as they pass through. This works well when you want to protect data without modifying the application itself, or when adding protection to a system you do not own the code for.

Application-layer protection: Your code calls transform directly before persisting a row, and again on read. This works well when you want a clean separation between protection logic and storage, or when multiple data stores are involved.

Database-layer protection: A trigger or stored procedure calls transform so that protection runs regardless of which client writes to the table. This works well when you control the schema and want a single point where protection happens.