Skip to main content

Federated authorization queries

Objective​

Explain how a federated authorization query joins context from the IdP, HRIS, data warehouse, ITSM, and SIEM into a single decision, and map each source to the input field the policy evaluates.

Concept​

A raw request rarely carries everything a good authorization decision needs. It knows the subject's identity and the resource id. It usually does not know whether the subject is still employed, what group they belong to today, how sensitive the resource is, whether there is an approved change ticket, or whether the subject is showing risky behavior right now. Herald's federation is what closes that gap: a single authorization query can pull context from several systems of record and hand the joined document to the PDP.

This is the PIP (Policy Information Point) role from the foundations course, done across many sources at once. A real deployment federates whatever systems you connect; the five below are the example set this course and its lab use, not a fixed product taxonomy. Each source answers one question the decision needs:

  • IdP (identity provider) — who the subject is and what groups or roles they hold. This is the source of subject.idp_groups.
  • HRIS (HR system) — employment reality: is this person an active employee, a contractor, or terminated. This is the source of subject.employment_status. A valid token from a terminated employee should still be denied, and HRIS is how the decision knows.
  • Data warehouse — the sensitivity of the thing being accessed. This is the source of resource.classification (for example public, internal, or restricted).
  • ITSM (change management) — whether a required approval exists, for example an approved change ticket for a sensitive action. This is the source of context.change_ticket.status.
  • SIEM (security monitoring) — live risk signal about the subject or session. This is the source of context.risk.level.

Herald joins those into one query document. The policy then evaluates all of it together, so the decision is not "does the subject have a valid token" but "given who they really are (IdP + HRIS), what they are touching (warehouse), whether it was approved (ITSM), and how risky things look right now (SIEM), should this proceed."

flowchart LR
  IDP[IdP: groups] --> H[Herald query]
  HRIS[HRIS: employment status] --> H
  WH[Warehouse: classification] --> H
  ITSM[ITSM: change ticket] --> H
  SIEM[SIEM: risk level] --> H
  H -->|joined input| PDP[OPA / Enterprise OPA]
  PDP -->|allow / deny| H

Text version of the diagram: the five example systems of record (IdP, HRIS, warehouse, ITSM, SIEM) each contribute one piece of context; Herald joins them into a single query document; the PDP evaluates the joined document and returns allow or deny.

The input the lab evaluates is exactly this joined document:

{
  "subject": { "idp_groups": ["analysts"], "employment_status": "active" },
  "action": "query",
  "resource": { "dataset": "revenue", "classification": "restricted" },
  "context": {
    "change_ticket": { "status": "approved" },
    "risk": { "level": "low" }
  }
}

Hands-on lab​

Open ../lab/policy.rego and connect every field it reads back to the source that federates it. For each of the five sources above, find the input path the policy checks and note which rule uses it. The restricted-dataset rule is the one that touches all five: IdP group, HRIS status, warehouse classification, ITSM ticket, and SIEM risk.

Then run the suite and watch the join decide the outcome:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/evaluate-with-herald -v

Run it from the cloned university-labs repo. Expected: PASS: 8/8.

Notice how the deny tests each knock out exactly one source of context: a terminated status (HRIS), a high risk level (SIEM), or a missing approval (ITSM) each flips an otherwise-allowable restricted query to deny. That is federation earning its keep. Any one bad signal from any one system is enough to withhold access.

Check for understanding​

  1. A request arrives with a valid token, but the subject was terminated yesterday. Which federated source carries that fact, and which input field does the policy read to catch it?
  2. In the lab, which single rule requires context from all five sources at once, and what does each source contribute?
  3. Why is resource.classification not something the raw request can be trusted to carry, and which system of record supplies it in a Herald query?