SmartExchange · .NET 10 · Chapter 01

Implementation overview

One shared authorization pipeline for Intaker and Web API. Applications prepare facts and enforce the result; Cerbos owns the authorization rules.

Shared code · Intaker + Web APIReviewed · 2026-10-27

The shared pipeline

ApplicationUser, product, resource and action
Context ResolverSelected, normalized grants
CerbosALLOW / DENY / condition
SQL adapterCondition added to the business query

The four BmcGroup.Authorization.* projects implement this pipeline. Intaker supplies its template query; Web API will supply its endpoint query. The shared packages must contain neither export-template logic nor HTTP endpoint logic.

What exists today

In source

Reusable libraries

Contracts, legacy grant conversion, context selection, scope validation, gRPC planning and parameterized SqlKata enforcement. Intaker calls these components.

Non-prod checked · 2026-10-27

Cerbos deployment

5 resource policies and 8 derived-role ConfigMaps. Mounted YAML compiles; the pod is 2/2 Ready. InterestedParty/read uses the new Project Scope contract.

Next integration

Shared NuGet delivery

Publish the libraries, align Person/Company policies with the current grants contract, integrate Web API and implement concrete-record attribute loading.

Source and runtime differ. Live Person/Company policies still use earlier principal attributes. Their new grant-based policies exist in the repository, but were not deployed as part of this documentation update.

Two equal export examples

Both examples follow the same steps and use the same shared implementation. Person export accepts a related Company/read grant. Proposed InterestedParty export accepts InterestedParty/read in Project scope. This read-to-export choice is explicit policy logic; it does not change the grant action or imply access from Project/read.

Step	Person export	InterestedParty export
Requested operation	`Person/export`	`InterestedParty/export`
Input grant	`Company/read/Resource`	`InterestedParty/read/Project`
CRM relation	`companyIds → Company`	`projectIds → Project`
Derived role	`person_with_readable_company`	`interested_party_in_project_scope`
Policy	`Person / presentation-demo`	`InterestedParty / presentation-demo`
SQL	`EXISTS PersonInCompany → Company`	`EXISTS Project`

Both complete derived-role and policy examples are in 05; both requests, expected plans and SQL examples are in 06.

The paired policies use the documentation-only version presentation-demo and are not deployed. Chapter 09 separately retains the verified InterestedParty/read migration.