Skip to content

Claims (Claim Packs)

This one feels backwards the first time you do it: you're about to define "who's allowed to ask" before you've written the Policy that will use it.

Why build this before the Policy that needs it?

If you're thinking about governance the way most people naturally do, you think in terms of a single rule: "Compliance can see SSNs, for audit purposes." The condition about who feels like a detail that belongs inside that one rule, not something to go build separately first.

Here's the problem that shows up the moment you have more than one Policy: several Policies usually need to check the same condition. "Relationship Management department, on a corporate device, during working hours" might gate access to Date of Birth in one Policy and National ID in another. If that condition were typed directly into each Policy, changing it, say, adding a new approved office, or tightening the working-hours window, means finding and editing every Policy that used it, and hoping you didn't miss one. That's exactly how governance rules quietly drift out of sync with each other.

A Claim Pack is that condition, defined once, as its own reusable object. Every Policy that references it evaluates the current version, so a single edit updates every Policy at once. It's the same reason Attributes exist separately from Policies, and Attribute Groups exist separately from individual Attributes: you define the reusable building block first, then assemble rules from it, rather than rebuilding the same logic by hand every time.

What a Claim Pack actually is

A Claim is a condition about the person or system making a request, for example their department, their device type, or the time of day. A Claim Pack bundles one or more Claims together into a reusable set. When a Policy references a Claim Pack, eXate checks whatever the calling application sends against each condition in the pack before deciding whether to grant unprotected access.

Portal Navigation

  1. Navigate to https://portal.exate.co/home
  2. Click "Claim Packs."

Creating the Claim Pack

  1. Click the blue "+" icon to add a new Claim Pack.
  2. Enter a Name for the Claim Pack.
  3. Optionally, enter a Description explaining what this Claim Pack checks and why.

Adding conditions

A Claim Pack is made up of one or more conditions. Each condition checks a claim (something the calling application sends about the requester) against a value you specify, using a Claim Source, Key, Condition (e.g. Equals), and Value.

When you add more than one condition, a logical operator (AND / OR) determines how they combine.

First condition: User Group

  1. Set Claim Source to Default, Key to ADGroup, Condition to Equals, and Value to the required group, for example Relationship Management.

This condition verifies the requester belongs to the right team before access is granted.

Second condition: Device Type

  1. Click "Add New Condition." Set the logical operator to AND, then configure Key as Device, Equals, Corp Device.

With AND selected, both this condition and the User Group condition above must be true. If you used OR instead, either one being true would be enough.

Third condition: Working Hours

  1. Add another condition with AND, Key ValidWorkHours, Equals, True.

This verifies the request falls within approved working hours. With all three conditions joined by AND, a request must satisfy all of them before the Claim Pack passes.

Saving

  1. Click "Save."

The Permitted toggle on each condition controls whether that condition needs to evaluate to True (Permitted) or False (Denied) for the Claim Pack to pass. Most conditions use Permitted, but Denied is useful for exclusion rules, for example blocking a specific device type outright.

Departments as a Claim Source

Department is the most common single condition used inside a Claim Pack, the "User Group" example above uses it directly. Departments are classified by default into HR, Finance, Management, Legal, and Sales; additional departments can be created as needed via Central Services → Data Management → Departments.

Click the "+" button at the top of the Departments page and fill in a Name. Click on any department to view or edit it.

Worked Example: Subject Entities & Access

Subject Entities are a related but distinct concept worth understanding alongside Claims: where a Claim describes who's making the request, a Subject Entity describes whose data it is. Access to Subject Entities is granted to Users the same way Claims scope access to Attributes, which is why this worked example lives here.

Subject Entity Type is a classification a new Subject Entity must be assigned, for example:

  1. Client
  2. VIP (additional approval required)
  3. VIP Plus (additional approval required)
  4. Sanctioned (additional approval required)
Video walkthrough

From an earlier product version, so field names or screens may have shifted slightly.

A Subject Entity is the actual record, depicting how a specific entity and the Applications it touches are mapped together via their respective identifiers. General details filled in when creating one:

  • Unique Username: must be unique; no duplicate Subject Entities are possible
  • Subject Entity Type: one of the types above
  • Country of Origin, Nationality, Domicile: the entity's country associations
  • Right to be Forgotten: whether this entity's private information can be removed from searches and directories under some circumstances (Yes/No toggle)

Example Subject Entities: Joe (Client), Smith (Client, Country of Origin: Luxembourg), Jeff B (VIP), Mac (VIP Plus).

Video walkthrough

From an earlier product version, so field names or screens may have shifted slightly.

Users are then granted access to specific Subject Entity Types, for example:

  • Relationship Manager 1: access to Subject Entity type "VIP"
  • Relationship Manager 2: access to Subject Entity type "VIP Plus"
  • Compliance Manager B: access to "VIP," "VIP Plus," and "Sanctioned"

See Admin → Users for how to grant a user access to specific Subject Entity Types.

Video walkthrough

From an earlier product version, so field names or screens may have shifted slightly.

What's next

With Attributes, Countries, and Claims all defined as reusable building blocks, you're ready for Policies, where the three come together into an actual governance rule.