This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Create a policy to protect Date of Birth (DOB)

Workflow example to protect DOB.

Goal

Create one policy that protects Date of Birth (DOB) using Datetime data element, with:

  • At least one role.
  • At least one member source feeding that role.
  • Deployed to at least one datastore.

This example provides a walkthrough of the complete workflow to create a policy to protect a Date of Birth (DOB). DOB is a common piece of sensitive personal data, and organizations typically protect it using datetime tokenization. This tokenization preserves the YYYY‑MM‑DD structure while preventing direct exposure of the original value. In this example, a single role is used whose members are obtained from an LDAP-based Member Source. The role is granted permission to protect (tokenize) DOB values.

For this walkthrough, a dedicated DOB data element is created using a date‑specific tokenizer, ensuring that the output maintains a valid date format for downstream systems. The role and data element are combined into a single policy. The policy is then deployed to a datastore so applications working with DOB information can enforce the protection rules at runtime.

Assumptions

To execute any CLI or API command in this example, the following assumptions have been made:

  • You are operating on a new AI Team Edition setup.
    • Set up the AI Team Edition by installing the Protegrity Provisioned Cluster. For more information about installing the PPC, refer to the section Installing PPC.
  • You are connected to the Policy Manager container.
    • Connect to the Policy Manager container by deploying the Protegrity Policy Manager. For more information about deploying the Protegrity Policy Manager, refer to the section Installing Policy Workbench.

CLI Examples

To execute any CLI command in this example, the following additional assumption has been made:

API Examples

To execute any API command in this example, the following additional assumption has been made:

  • You have access to the Protegrity Policy Management REST APIs.

1 - Initialize Policy Management

Initialize the policy management.

This step initializes the Policy Information Management system. This step needs to be executed only once.

CLI Code

pim invoke init

CLI Actual Output

✅ PIM successfully initialized (bootstrapped).

API Endpoint

POST /pim/init

Get Gateway host address

export GW_HOST="$(kubectl get gateway pty-main -n api-gateway -o jsonpath='{.status.addresses[0].value}')"

Generate JWT token

TOKEN=$(curl -k -s  https://$GW_HOST/api/v1/auth/login/token \
## -X Post \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'loginname=workbench' \
-d 'password=Admin123!' \
-D - -o /dev/null 2>&1 | grep -i 'pty_access_jwt_token:' | sed 's/pty_access_jwt_token: //' | tr -d '\r') && echo "${TOKEN:0:10}"

API Code

curl -k -H "Authorization: Bearer ${TOKEN}" -X POST "https://{$GW_HOST}/pty/v2/pim/init" -H "accept: application/json"

API Actual Output

The API does not return any output as response.

2 - Prepare Data Element

Prepare data element.

What you are doing

Creating a DOB data element that defines what is protected (Date of Birth) and how it is protected using date tokenization in YYYY-MM-DD format.

Why it matters

Data elements are the protection building blocks that policies grant access to.

CLI Code

pim create dataelements token date-time --name "de_dob_token" --description "Tokenize Date of Birth" --tokenizer "SLT_8_DATETIME"

CLI Actual Output

UID  NAME          DESCRIPTION             TOKENIZER       TOKENIZETIME  DISTINGUISHABLEDATE  DATEINCLEAR
1    de_dob_token  Tokenize Date of Birth  SLT_8_DATETIME  False         False                TokenElementDateInClear.NONE

API Endpoint

POST /pim/dataelements

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/dataelements" \
-d '{
"name": "de_dob_token",
"description": "Tokenize Date of Birth",
"dateTimeToken": {
"tokenizer": "SLT_8_DATETIME",
"tokenizeTime": false,
"distinguishableDate": false,
"dateInClear": "NONE"
}
}'

API Actual Output

{"uid":"1","name":"de_dob_token","description":"Tokenize Date of Birth","dateTimeToken":{"tokenizer":"SLT_8_DATETIME","tokenizeTime":false,"distinguishableDate":false,"dateInClear":"NONE"}}

3 - Create Member Source

Create member source.

What you are doing

You are creating a Member Source, which is a source that informs Protegrity where user identities are stored. For example, Active Directory, LDAP, Azure AD or a text file. This configuration stores the connection and the lookup context that Protegrity needs to discover users and groups that are then mapped to Roles.

Why it matters

Policies do not grant access to individual users directly. Access is granted through roles, and roles are populated from external identity systems via member sources. Without a source, you cannot reliably attach real enterprise groups or users to roles, synchronize memberships, or enforce policy access the same way your organization manages identity.

CLI Code

pim create sources file --name test-file --user-file exampleusers.txt --group-file examplegroups.txt

CLI Actual output

NAME       DESCRIPTION  TYPE             USERFILE          GROUPFILE          TIMEOUT  UID
test-file               SourceType.FILE  exampleusers.txt  examplegroups.txt  120      1

API Endpoint

POST /pim/sources

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/sources" \
-d '{
"name": "test-file",
"type": "FILE",
"connection": {
"userFile": "exampleusers.txt",
"groupFile": "examplegroups.txt"
}
}'

API Actual output

{"name":"test-file","description":"","type":"FILE","connection":{"userFile":"exampleusers.txt","groupFile":"examplegroups.txt"},"uid":"1"}

3.1 - Test the Member Source

Test whether the member source has been successfully created.

CLI Code

pim invoke sources test 1

CLI Actual Output

+----------------+--------+---------+
|      type      | passed | message |
+----------------+--------+---------+
|   connection   |  True  |         |
| authentication |  True  |         |
|     groups     |  True  |         |
|     users      |  True  |         |
+----------------+--------+---------+

API Endpoint

POST /pim/sources/{SOURCE_UID}/test

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/sources/1/test"

API Actual Output

{"connection":{"passed":true,"message":""},"authentication":{"passed":true,"message":""},"groups":{"passed":true,"message":""},"users":{"passed":true,"message":""}}

4 - Create Role

Create a role.

What you are doing

Creating the role that represents who can perform operations against the DOB data element.

Why it matters

Permissions are granted to roles, and roles map to real users or groups via member sources.

Tips

  • If you keep the --allow-all option in the command, then set ALLOWALL to True.
  • Consider which user needs what level of access and create a role for each set of users.

CLI Code

pim create roles role --name "dob_protect_role" --description "Role having access to protect DOB" --mode "MANUAL"

CLI Actual Output

NAME              DESCRIPTION                        MODE             ALLOWALL  UID
dob_protect_role  Role having access to protect DOB  RoleMode.MANUAL  False     1

API Endpoint

POST /pim/roles

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/roles" \
-d '{
"name": "dob_protect_role",
"description": "Role having access to protect DOB",
"mode": "MANUAL",
"allowAll": false
}'

API Actual Output

{"name":"dob_protect_role","description":"Role having access to protect DOB","mode":"MANUAL","uid":"1","allowAll":false}

5 - Assign Member Source to Role

Assign member source to a role.

What you are doing

You are attaching a specific user or group from a member source to a role. This creates the who belongs in this role binding. If you run synchronization, it retrieves the current membership from the source into the role.

Why it matters

This is the step that turns a role from a named container into an identity-backed access control object. If you do not assign a source user or group to the role and synchronize it, then no real identities are associated with that role. This means that your policy rules may exist, but nobody in your organization will actually have the access that those rules intend to grant.

CLI Code

pim create roles members 1 --member "exampleuser1,1,USER"

CLI Actual Output

## Name          Source  Type             Uid
exampleuser1  1       MemberType.USER  1

API Endpoint

POST /pim/roles/{SOURCE_UID}/test

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/roles/1/members" \
-d '[
{
"name": "exampleuser1",
"source": "1",
"type": "USER"
}
]'

API Actual Output

[{"type":"USER","name":"exampleuser1","syncid":"exampleuser1","uid":"1","source":"1"}]

5.1 - Synchronize Member Source

Synchronize the member source.

Connect and synchronize the users with your member source.

CLI Code

pim invoke roles sync 1

CLI Actual Output

Successfully synchronized members for role with UID '1'.

API Endpoint

POST /pim/roles/{SOURCE_UID}/sync

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/roles/1/sync"

API Actual Output

The API does not return any output as response.

6 - Create Policy Shell

Create a policy shell.

What you are doing

Creating the policy that will hold the access rules. For example, Data Element, Role, and Rules.

Why it matters

The policy is the object that ties together the pieces and becomes deployable.

Tips

Multiple roles, multiple data elements, and their corresponding rules can be added to a single policy. Consider structuring your policy around specific areas of focus. For example, how the DOB is used across the entire enterprise.

CLI Code

pim create policies policy --name "dob-policy" --description "Protect DOB with tokenization"

CLI Actual Output

NAME        DESCRIPTION                    ACCESS                                                      UID
dob-policy  Protect DOB with tokenization  {'protect': False, 'reProtect': False, 'unProtect': False}  1

API Endpoint

POST /pim/policies

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/policies" \
-d '{
"name": "dob-policy",
"description": "Protect DOB with tokenization",
"template": {
"access": {
"protect": false,
"reProtect": false,
"unProtect": false
}
}
}'

API Actual Output

{"name":"dob-policy","description":"Protect DOB with tokenization","uid":"1","template":{"access":{"protect":false,"reProtect":false,"unProtect":false}}}

7 - Define Rule with Data Element and Role

Define a rule that includes the data element and role.

What you are doing

Creating the policy rule that binds:

  • A role: Who.
  • A data element: What.
  • Permitted operations: Protect, Reprotect, or Unprotect.

Why it matters

This binding is what makes the policy enforceable. Without rules, the policy exists but grants no access.

Tips

This rule grants the specified role permission to protect and unprotect to the DOB data element, while disallowing reprotect.

CLI Code

# Format:
# "roleUid,dataElementUid,,NOACCESSOPERATION,protect,reProtect,unProtect"

pim create policies rules 1 --rule "1,1,,NULL_VALUE,true,false,true"

CLI Actual Output

## Role  Dataelement  Mask  Noaccessoperation  Access
1     1            0     NULL_VALUE         {'protect': True, 'reProtect': False, 'unProtect': True}

API Endpoint

POST /pim/policies/{POLICY_UID}/rules

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/policies/1/rules" \
-d '{
"role": "1",
"dataElement": "1",
"mask": "0",
"noAccessOperation": "NULL_VALUE",
"permission": {
"access": {
"protect": true,
"reProtect": false,
"unProtect": true
}
}
}'

API Actual Output

{"role":"1","mask":"0","dataElement":"1","permission":{"access":{"protect":true,"reProtect":false,"unProtect":true}}}

8 - Create Datastore

Create a datastore.

What you are doing

Creating the datastore target where a policy will be deployed.

Why it matters

A policy is not active for protectors until it is deployed to a datastore.

CLI Code

pim create datastores datastore --name "ds_protect_dob" --description "Datastore to demonstrate DOB protection" --default

CLI Actual Output

## Name            Description                              Default  Uid
ds_protect_dob  Datastore to demonstrate DOB protection  True     1

API Endpoint

POST /pim/datastores

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/datastores" \
-d '{
"name": "ds_protect_dob",
"description": "Datastore to demonstrate DOB protection",
"default": true
}'

API Actual Output

{"description":"Datastore to demonstrate DOB protection","name":"ds_protect_dob","default":true,"uid":"1"}

9 - Deploy Policy to Datastore

Deploy the policy to a datastore.

What you are doing

Deploying the policy to the datastore so protectors that target that datastore can load the policy.

Why it matters

Until the policy is deployed, the policy is not available to runtime protectors.

Tips

  • You may want to deploy the multiple policies to a single datastores. If so, include them by repeating the –-policies option in the command.
  • You can also add a single policy to multiple datastores by creating a loop.

CLI Code

pim invoke datastores deploy 1 --policies 1

CLI Actual Output

Successfully deployed to datastore '1':
Policies: 1

API Endpoint

POST /pim/datastores/{DATASTORE_UID}/deploy

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://${GW_HOST}/pty/v2/pim/datastores/1/deploy" \
-d '{
"policies": ["1"],
"applications": []
}'

API Actual Output

The API does not return any output as response.

10 - Confirm Deployment

Confirm the policy deployment.

What you are doing

Confirm that the policies have been deployed to the respective datastores.

Why it matters

Verifying deployment confirms the policy is active, correctly mapped, and enforceable.

CLI Code

pim get deploy

CLI Actual Output

## Uid  Policies  Applications
1    ['1']     []

API Endpoint

POST /pim/deploy

API Code

curl -k \
-H "Authorization: Bearer ${TOKEN}" \
-H "accept: application/json" \
-X GET "https://${GW_HOST}/pty/v2/pim/deploy"

API Actual Output

{"dataStores":[{"uid":"1","policies":["1"],"applications":[]}]}