Standards-Based Integration Architecture

Two planes, two standards

Identity integration splits cleanly into a slow, stateful provisioning plane and a fast, event-driven signaling plane. Governance lives on the first; continuous, real-time reaction lives on the second. Every hook into the fabric uses one or both.

flowchart LR
  HRIS[HRIS-Lite\nsource of record] --> IGA[IGA-Lite\ngovernance / JML]
  REQ[Self-service\naccess request]:::req --> IGA
  CMDB[CMDB-Lite\nCI / device trust] -.enriches.-> IGA
  IGA -->|F3 · RFC| ITSM{ITSM-Lite\nchange gate}
  ITSM -->|Duo push · SG-CAB-Approvers RBAC\nserialized · SoD| CAB([CAB approver]):::cab
  CAB -->|approve / deny · F4| ITSM
  ITSM -->|SCIM / Admin API| DUO[Duo]
  ITSM -->|SCIM / LDAPS| AD[AD / Entra]
  ITSM -->|SCIM| PACS[PACS-Lite\nthe door]
  subgraph SIG[Signaling plane — SSF]
    TX[VIGIL SSF\ntransmitter]
  end
  IGA -->|lifecycle → RISC| TX
  IGA -->|grant applied → assurance-level-change| TX
  CMDB -->|posture → CAEP| TX
  TX -->|CAEP / RISC| DUO
  TX -->|CAEP / RISC| CII[CII / Oort]
  TX -->|CAEP / RISC| PACS
  TX -->|CAEP / RISC| APPS[Apps / RPs]
  PACS -.badge-in = presence.-> TX
  classDef req fill:#160f22,stroke:#3b3170,color:#e6edf3;
  classDef cab fill:#201a10,stroke:#a98f2a,color:#f0f6fc;
    

The Change Approval Board — how the gate approves

The ITSM gate doesn't auto-approve grants — it requires a human CAB decision, authenticated by a Duo push. The push goes only to members of the SG-CAB-Approvers AD security group — the RBAC source of truth, resolved from AD and stamped into every RFC — so approver identity is governed, not hardcoded.

Requests arrive two ways — birthright (persona-derived) and self-service (the /request intake) — and both flow through the same gate: RFC → Duo-push CAB → approve → apply → assurance-level-change. Every decision lands on the tamper-evident audit spine and the Grafana Change Approval Board row.

Where SSF fits — and how

You already built the hard part. The VIGIL SSF/CAEP stack (transmitter :8001 · receiver :8002 · bridge :8003, SSF 1.0 / CAEP 1.0) is live on its own tunnel and verified interop with caep.dev and with CII/Oort (a real session-revoked push returned HTTP 202). The SCIM→RISC leg already maps lifecycle changes to RISC events. So SSF isn't something to add — it's the spine that turns the fabric from a set of point integrations into a broadcast bus.

The role each standard plays

Lane: the SSF/CAEP stack is Personal/R&D (vigil-ssf-poc) — standards plumbing only. The patentable CIAF scoring core is Voxiren IP and stays deferred until IP assignment; it plugs into the one ciaf_seam boundary. Nothing here builds the scoring engine.

PACS as the fifth hook

Physical access is the last identity domain the fabric doesn't govern. Modern PACS (Verkada, Avigilon Alta, Brivo) now ship native SCIM + webhooks, so the door governs exactly like a Duo group — through the same two planes, three concrete hooks:

flowchart TB
  subgraph FABRIC[Lab Identity Governance Fabric]
    IGA2[IGA-Lite] --> ITSM2{ITSM gate}
    TX2[SSF transmitter]
  end
  ITSM2 -->|1 · SCIM target\nbadge granted on hire,\nrevoked on leaver| PACS2[PACS-Lite]
  TX2 -->|2 · SSF receiver\nrevoke on session-revoked /\naccount-disabled — instantly| PACS2
  PACS2 -->|3 · SSF transmitter\nbadge-in = presence signal| TX2
  TX2 -.assurance / impossible-travel\nbadge-in vs SSO login.-> RISK[CIAF assurance\nVoxiren · deferred]
    

Badge enrollment — RFIDeas Universal Enroll SDK

Before a badge can be governed it has to be bound to an identity. PACS-Lite enrolls the physical credential with the RFIDeas Universal Enroll SDK — an enrollment reader (pcProx / WAVE ID) reads the card's CSN (or iCLASS facility + ID) and PACS-Lite ties it to the worker, so the same JML that provisions the account also provisions the door.

Lane: PACS-Lite functionality, design, and integration/interoperability are personal IP (Voxiren) — the RFIDeas enrollment leg and the badge-vs-SSO impossible-travel signal are part of that IP; the CIAF assurance core stays deferred until IP assignment.

Adoption path (PACS-Lite POC)

Duo on the lab's AD — and how CII sees it

Open standards cover the new systems; the lab's legacy AD is covered by Duo's on-prem protection surfaces, and Cisco Identity Intelligence ingests AD directly.

Windows Logon + Legacy AD + Command-Line Protection close the MFA gap across every AD logon path — interactive, legacy-app, and remote shell — while the CII AD ingest folds on-prem AD into the same identity-intelligence plane (Oort · Astrix · BHE) as cloud and SaaS.

Credential vaulting — 1Password, the lab's CyberArk

Governance decides who may hold a credential; a vault holds the secret itself and brokers every checkout. The lab runs 1Password as its PAM/vault tier — the same split CyberArk draws between PVWA (people) and CCP / AAM (machines):

This closes the loop with the ownership model: a service account's identity is governed in the NHI registry while its secret is vaulted in 1Password — human-checkout for break-glass, machine-fetch via Connect for the account itself. Personal/CastleOps lane; secrets never land in the repo.