Access Control (RBAC/ABAC)
Enforces who can read, write, or modify lakehouse data based on role and attribute — the runtime enforcement of the Policies & Entitlements metadata.
High-Level Design
Access Control is checked before any data is returned, on every query.
💼 Business Context
- The direct control that prevents unauthorized access to customer data — a compliance and trust requirement, not optional
- Role-based access lets the platform scale to many teams without a manually managed permission list per table
- Owned by Security / Data Governance
🔌 Technical Overview
RBAC assigns broad table-level permissions via Azure AD (Entra ID) group membership (e.g., 'data-engineering' can read raw and curated zones). Internal/employee identities — support agents, analysts, engineers — authenticate through the enterprise's existing on-prem Active Directory, federated into Azure AD via ADFS (SAML/WS-Federation), so staff use their corporate SSO credentials rather than a separate Azure-only account; customer-facing identities remain on Azure AD B2C, kept entirely separate. ABAC layers finer-grained, attribute-based rules on top of either identity source — e.g., 'customer-support agents can read profile data only for customers in their assigned region.' Both are evaluated by the same shared policy library described under Policies & Entitlements, checked on every query before data is returned.
Model
💾 Access Decision
{
"principal": "agt_302",
"identity_source": "adfs-federated",
"role": "customer-support-tier1",
"resource": "curated.customer_profile",
"decision": "allow",
"constraints": { "column_mask": ["email", "phone"] }
}
🔗 Integration Points
- Azure AD (Entra ID) — role and group source of truth
- ADFS — federates on-prem enterprise Active Directory into Azure AD for internal/employee SSO
- Policies & Entitlements metadata — defines the rules RBAC/ABAC evaluates
- Shared policy-evaluation library — enforced consistently across every lakehouse-reading service
- Audit Logs — every access decision is logged
🧰 Services Consumed
- Owning microservice —
Cxos.Foundation.Api(see the Full Application Service Map) - Database — ADLS Gen2 (Iceberg) + Azure Database for PostgreSQL (policy/retention state)
⚠️ Non-Functional Considerations
- Scale: policy evaluation adds negligible overhead per query regardless of lakehouse size
- Latency: sub-millisecond policy checks via cached role/attribute lookups
- Reliability: fail-closed by design — an evaluation error denies access rather than defaulting to allow
- Security/Privacy: a foundational security control; access decisions are themselves logged for audit, and ADFS federation means no separate password store exists for internal accounts to compromise
🎯 Enterprise Example
A support agent signs in via ADFS-federated SSO using their existing corporate AD credentials, based in the EU, and tries to query a US customer's profile. ABAC's region-attribute rule denies the request even though their RBAC role would otherwise permit customer-profile access — a more precise control than role alone could provide.