Authorization now extends beyond the RBAC, ABAC, ReBAC, and Feature evaluators. Its management surface includes field-level security, data classification, unified sharing authorization, delegated administration, reverse permission reports, effective-permission simulation, and workflow-backed temporary grants. They share trusted tenancy, stable subject keys, optimistic concurrency, stable errors, and audit boundaries, but solve different problems.

1. Capability map

Capability	Question answered	Current production adoption
Field security	Who may see or change a field?	`identity.user`, 22 public fields and 11 surface types
Data classification	How does a tenant classify a field?	`Default`, `Sensitive`, `Restricted`
Sharing rules	May a non-owner subject read or write an instance?	`tickets.ticket`, including detail, list, search, attachments, export, and commands
Delegated admin	Which users are inside an administrator’s scope?	Office, Department, UserGroup
Permission audit	Where did an effective capability come from?	roles, scopes, sharing, fields, delegation, temporary requests
Permission simulation	Why would a request be allowed or denied?	catalog plus read-only simulation
Access request	Can approval create a time-bounded role source?	standard Workflow, revocation, expiry, and submission recovery

This is the registered scope today, not automatic coverage for every module. A new owner must contribute a catalog, execution manifest, and contracts bound to real consumers. Adding only an administration page does not secure business reads and writes.

2. Field security

Data owners contribute the field catalog at compile time; tenants cannot invent resource or field codes. The current identity.user resource exposes 22 public fields covering identifiers, profile data, organization relationships, roles, account state, and guest data. Passwords, hashes, tokens, and internal search hashes never enter the catalog.

Read effects merge least-privilege-first as Hidden > Masked > Visible; write effects merge as ReadOnly > Editable. Policy subjects are tenant roles and Identity user groups. Runtime evaluation reloads authoritative relationships instead of trusting client input or stale JWT role claims. Without an explicit policy, the owner baseline applies. For example, phone is Masked by default and its SensitiveEncrypted protection cannot be disabled by tenant policy.

Every catalog resource needs bindings to real execution surfaces. identity.user covers detail, list, lookup, create, update, import, batch, export, search, audit projection, and workflow response. Missing, duplicate, or mismatched catalog and execution registrations fail the catalog closed.

Method and route	Semantics
`GET /api/authorization/field-security/resources`	owner field catalog
`GET /api/authorization/field-security/policies`	paged resource, field, subject, and state query
`POST /api/authorization/field-security/preview`	side-effect-free complete matrix preview
`PUT /api/authorization/field-security/policies/bulk`	inherit or override a subject matrix
`POST/PUT/DELETE .../policies[/{policyId}]`	individual policy lifecycle

Management uses authorization.field-security.view and .manage. Writes use Version. Inherit=true removes the explicit policy and restores the owner baseline.

3. Classification is not field authorization

Classification records a tenant’s Default, Sensitive, or Restricted label for a field and feeds scan, display, search, export, and logging governance. Field security decides Visible/Masked/Hidden and Editable/ReadOnly for a concrete subject. Neither replaces the other.

GET /api/authorization/data-classification/catalog/{resourceCode} returns owner fields and explicit overrides. PUT /api/authorization/data-classification/{resourceCode}/{fieldCode} saves with ExpectedVersion. POST .../impact-preview reports how many field-security policies reference the field before a classification change. Unknown resources, fields, and labels fail with stable errors instead of persisting arbitrary strings.

Sharing is an allow-only addition; it cannot override explicit Deny, RBAC, DataScope, or owner relationships. Rules evaluate an owner-defined field catalog, a current authoritative resource snapshot, and current subject relationships. Targets may be User, UserGroup, or Role, and the granted level is Read or Write.

Only tickets.ticket currently has a complete production manifest. Its rule fields are status, priority, type, severity, requesterId, assigneeId, projectId, sprintId, tags, and dueAt. Conditions support All/Any, equality, sets, emptiness, and time comparisons. Business code must use ISharingResourceAuthorizationResolver rather than interpret raw rules directly.

The HTTP surface provides resource discovery, CRUD, side-effect-free preview, authoritative decision, and resumable impact scanning:

GET /api/authorization/sharing/resources
GET/POST /api/authorization/sharing/rules
GET/PUT/DELETE /api/authorization/sharing/rules/{ruleId}
POST /api/authorization/sharing/rules/preview
POST /api/authorization/sharing/decision
POST .../{ruleId}/recalculations and POST .../{operationId}/advance

Online authorization still reevaluates current rules and owner snapshots. Recalculation is impact and operational evidence, not a cache prerequisite for correctness.

5. Delegated administration

A delegated grant binds allowed management permission codes to a user scope. Scopes are Identity-validated Office, Department, or UserGroup references. A grant may be scheduled, expire absolutely, or be revoked; update and revoke operations use Version.

/api/authorization/delegated-admin/catalog returns delegable actions and risk levels, /preview expands current members, and /effective returns the current caller’s union of effective actions and scopes. User and access-request services enforce that scope on the server. Filtering a frontend list is not isolation.

6. Permission audit and simulation

The reverse permission report starts from a subject and combines Role, UserGroup, Position, ReportingRelationship, DataScope, SharingRule, FieldSecurityPolicy, DelegatedAdmin, and PermissionRequest sources. GET /api/authorization/permission-audit returns paged details; POST .../export creates an asynchronous export, with a separate export permission.

GET /api/authorization/permission-simulation/catalog lists simulatable resources and actions. POST /api/authorization/permission-simulation executes the read-only authorization chain and returns effective subjects, matched policies, obligations, and the final reason. It creates no relationship, temporary grant, or business resource and does not replace owner validation of resource facts.

7. Workflow-backed access requests

An access request does not insert a commented permanent UserRole. SysPermissionAccessRequest is the temporary authorization source. Online RBAC reads require completed approval, no revocation, and server time before ExpiresAt, so a delayed cleanup job cannot extend access.

An empty target means the current caller. The server validates target, role, reason, and ExpiresAt and rejects a duplicate open request for the same target and role. A requester cannot self-approve; rejection requires a comment; only the requester can cancel or retry SubmissionFailed; revoking Active access requires a reason and ExpectedVersion.

The Workflow hook uses taskId as the duplicate-approval idempotency key, reserves Provisioning before workflow advancement, and activates only after commit. RequestId is also the stable workflow business key, so a failed start can be recovered without starting duplicate processes.

8. HTTP and permission boundaries

The current OpenAPI contains 46 /api/authorization paths. Management routes still derive permissions through the common ResourceDescriptor. Personal mine routes constrain results to requests created by or targeting the current subject; omitting the management-style request interface does not remove that subject boundary.

Clients distinguish catalog/owner unavailability, cross-tenant input, inactive subjects, version conflicts, invalid rules, out-of-scope administration, already-decided requests, expiry, and workflow submission failure. Do not collapse 403, 409, 422, and 503 into “save failed.”

9. Regression matrix

Field policy covers detail, list, search, import, export, audit, and workflow projections; Masked/Hidden data does not leak through sort, filter, or alternate projections.
Identity role and group changes affect field decisions through authoritative relationships.
Ticket sharing covers detail, list, search, comments, attachments, export, and commands; cross-tenant owner snapshots fail closed.
Delegated admin tests base RBAC, delegated action, member scope, expiry, and revocation independently.
Permission audit and simulation explain the same authoritative decision; export retains field and tenant controls.
Access requests cover self-approval denial, duplicate open requests, submission retry, duplicate approval, expiry, revocation, and cache invalidation.
SqlSugar and EF Core agree on strategy tables, natural keys, soft deletion, and Version behavior.

10. Source verification

Verify generated endpoints, actions, owner seams, and the production manifest before running behavioral regressions. This separates a missing entry point from an incorrect decision:

# Entry points, actions, owner seam, and field-security execution surfaces.
rg -n "GenerateEndpoint|AuthorizationAction|ISharingResourceAuthorizationResolver" \
  src/Platform/Authorization -g '*.cs'
rg -n "requiredExecutionSurfaces|tickets.ticket" \
  docs/architecture/00-governance/manifests/0017-field-security-resource-catalog.json

# Advanced authorization use cases, owner adoption, and workflow requests.
dotnet test tests/BitzOrcas.Application.Tests \
  --filter "FullyQualifiedName~FieldSecurity|FullyQualifiedName~Sharing|FullyQualifiedName~DelegatedAdmin|FullyQualifiedName~PermissionRequest"

# Catalog completeness, execution bindings, and persistence isolation.
dotnet test tests/BitzOrcas.Architecture.Tests \
  --filter FullyQualifiedName~Authorization

Previous: configuration, persistence, and cache · Authorization overview