# A Record-Level Authorization Layer for USACE Civil Works Data

How Solid Logix added granular access control to a live USACE Civil Works data environment. Delivered ahead of schedule, with excellent CPARS performance, and no disruption to the legacy system in active use.

## Mission Context

### The system behind how the U.S. manages its water

The **Corps Water Management System (CWMS)** is the U.S. Army Corps of Engineers' authoritative platform for managing the nation's reservoirs, dams, locks, and river systems. It sits at the center of how USACE's Hydrologic Engineering Center (HEC) coordinates flood response, navigation, hydropower, and water supply operations. CWMS continuously ingests real-time hydrometeorological data, river stages, reservoir elevations, gage and radar precipitation, and quantitative precipitation forecasts, to model watershed response and short-term reservoir inflows before release decisions are made.

CWMS data flows into applications, district workflows, analyst tooling, and partner systems at NOAA and USGS. Every river-stage reading, reservoir-storage record, and forecast value is consumed by people making decisions that affect public safety, infrastructure, and billions of dollars of downstream activity.

The program needed **finer-grained access control** so that different users, roles, and systems could see exactly the records they were entitled to, the access management pillar of the federal **ICAM (Identity, Credential, and Access Management)** framework. The application was live, in production, and could not be disrupted while the change was introduced.

### CWMS at a Glance

- **Authoritative source for**: U.S. Army Corps of Engineers water resources data
- **Managed by**: USACE Hydrologic Engineering Center (HEC)
- **Consumed by**: USACE districts, NOAA, USGS, partner systems, and analyst tooling
- **Operational footprint**: More than 700 reservoirs, locks, and other water control structures nationwide
- **Deployed across**: 35+ USACE District and Division offices, operating 24/7
- **Tolerance for downtime**: None. Decisions ride on it 24/7, especially during flood events

## The Problem

### A live federal system whose access model could no longer keep up with the data it managed

CWMS has been operationally critical for years, which is exactly why its access controls had calcified around the technology choices of an earlier era. Three pressures converged.

1. **CWMS data sprawl**  
   CWMS is the authoritative source for U.S. Army Corps water resources data, consumed across districts, partner agencies, and downstream applications. Every record has different sensitivity, different ownership, and different audiences. The access model had to keep up.

2. **Oracle VPD reliance**  
   Access was enforced almost entirely through Oracle Virtual Private Database (VPD) policies. Those policies were coupled to the schema, tied to a specific database vendor, and difficult to evolve without touching the live production database. Every authorization change was a database change.

3. **A coarse RBAC model that could not keep up**  
   Access rested on a coarse role-based access control (RBAC) model: exactly two privileges at the office (district) level, Modifier and Administrator. That was nowhere near enough to express the way USACE actually operates. Dam operators work within specific shift hours. Water managers need overrides on embargoed data during emergencies. Automated collectors should only append, never modify. External cooperators are limited to specific parameters. Partner agencies carry legal hold obligations on their own data. Capturing those distinctions in roles alone would mean a role explosion; they are really attribute-based (ABAC) decisions.

## Non-Negotiables

### Two constraints we set before writing any code

These weren't aspirations. They were success criteria. Anything that broke either of them broke the engagement.

### Operational Continuity

**Don't break the legacy system**  
   CWMS was live, in production, with established integrations and workflows. Districts, partner agencies, and analyst tooling depended on it around the clock. Any solution that required pausing the system, rewriting application logic, or coordinating a multi-district cutover was off the table.

### Performance Posture

**Don't add measurable latency**  
   Authorization runs on every request. A new access control layer that pushed query times into the warning range during flood response surge traffic would be worse than the gaps it closed. The new model had to disappear into the request path rather than show up in it.

## The Approach

### Understand first, model second, validate against reality before touching production

The risk of a project like this is rarely the technology. It's mismatching the new access model to the way districts actually use their data. We sequenced the work to remove that risk before code shipped.

### Step 1

**Understand the users and the roles**  
   Cataloged how access decisions were actually being made at the API layer, at the database layer, and inside the application. Mapped the real relationships between USACE districts, water managers, dam operators, public users, automated systems, and the data each one legitimately needed.

- API authentication and authorization mechanisms
- Oracle VPD policy logic and enforcement points
- District data ownership and embargo conventions
- Partner agency consumption patterns (NOAA, USGS)

### Step 2

**Model the real personas, not just the legacy roles**  
   Interviews with HEC staff, district users, and program office stakeholders surfaced thirteen distinct personas, well beyond the original two-role baseline. The model expressed each one declaratively, with attributes such as office, data classification, embargo window, and source type layered over role to capture how districts actually own their records.

- Core personas from the PWS: Public, Dam Operator, Water Manager, Data Manager, Auto Collection, Auto Processing, External Cooperator
- Refined personas from stakeholder interviews: Facilities Staff, Authorization Admin, Data Steward (QA), Diagnostics Engineer, Partner Data Controller, Water Quality Manager
- Attributes layered over role: office, classification, embargo window, source type, parameter scope

### Step 3

**Validate against the existing VPD**

Before swapping anything, we ran the new policy logic in parallel against the existing Oracle VPD enforcement. Same requests, same data, same users, two enforcement paths in lockstep. If the new model produced a different answer than VPD, we resolved the gap in the model rather than in production.

- Dual policy validation against the live VPD enforcement
- Staging environment for behavior comparison testing
- No production cutover until both paths returned identical decisions
- Edge case handling for overlapping roles and dynamic user contexts

## The Solution

### A transparent authorization layer, sitting in front of the system that was already working

Instead of rewriting CWMS's access logic in place, Solid Logix introduced authorization as a **policy layer in front of** the existing data API, powered by **Open Policy Agent (OPA)**. Every request still hits the application. Every record still lives in the same database. What changed is that the access decision now happens in a centralized, auditable policy layer, written in Rego, version controlled in Git, and passed into the data API through an `x-cwms-auth-context` header.

Application code stayed the same. Oracle VPD policies stayed in place as a defense in depth backstop. Districts saw zero workflow change. In effect this moved CWMS from a coarse **role-based (RBAC)** model to an **attribute-based (ABAC)** one: the new layer evaluated each request against the user's persona plus the attributes the program office actually needed, including embargo windows, shift hour validation, append-only enforcement, and parameter whitelisting, without coupling any of them to the schema.

### How a request flows

1. **CWMS Application & APIs**  
   Unchanged. Same code, same endpoints, same workflows.

2. **Authorization Layer (OPA)**  
   Open Policy Agent. Rego policies in Git. Persona and attribute decisions. Auditable. Externalized.

3. **Oracle Database & VPD**  
   In place. Defense in depth. Production of record.

Application + database are untouched. The new enforcement point lives between them, governed by an external policy layer the program office controls.

## Try It Live

### The authorization model, as a sandbox

Choose a persona, an action, and the request context. The decision is evaluated the same way the policy layer does, then shows you exactly which conditions it checked. This is the move from role-based (RBAC) to attribute-based (ABAC) access in action, and it mirrors the OPA / Rego persona rules from the published CWMS authorization model.

### Build a request
- **Persona**: Anonymous / Public, Dam Operator, Water Manager, Data Manager, Automated Collection System, Data Steward (QA), Automated Processing System, External Cooperator, Facilities Staff, Authorization Admin, Diagnostics Engineer, Partner Data Controller, Water Quality Manager
- **Action**: create, read, update, delete
- **Data source**: Manual, Automated sensor, Derived / calculated
- **Request context**: ✓ Same office as user, ✓ Within shift hours (06:00–18:00), ✓ Within 24h edit window, ✓ Data under embargo, ✓ Forward-dated (new) reading, ✓ Edit touches only QA flags, ✓ Justification provided, ✓ Second-person delete approval, ✓ Parameter in whitelist

### Allow
- **Dam Operator** · update

Conditions evaluated
- ✓ Resource office is in user's offices
- ✓ Data source is "manual"
- ✓ Within shift hours (06:00–18:00)
- ✓ Within 24h modification window

### Matching policy
```rego
package cwms.authorization.dam_operator

allow {
  input.user.persona == "dam_operator"
  input.resource.office in input.user.offices
  input.resource.data_source == "manual"
  within_shift_hours
  within_modification_window
}

within_shift_hours {
  hour := time.clock([time.now_ns(), "America/Los_Angeles"])[0]
  hour >= 6
  hour < 18
}

within_modification_window {
  time.now_ns() - input.resource.created_at < 24 * 3600000000000
}
```

### Policy input
```json
{
  "user": {
    "persona": "dam_operator",
    "offices": ["EXAMPLE-DISTRICT-A"]
  },
  "resource": {
    "type": "timeseries",
    "office": "EXAMPLE-DISTRICT-A",
    "data_source": "manual",
    "embargoed": false,
    "parameter": "SAMPLE_PARAM"
  },
  "action": {
    "op": "update"
  },
  "context": {}
}
```

## Zero-Disruption Delivery

### The legacy system kept running. The access model got better.

Oracle VPD stayed in place as defense in depth. Application code stayed the same. Districts noticed nothing.

- **Before**: Access policies embedded in Oracle VPD. Tightly coupled to the schema. Coarse role grants that didn't match the way districts owned their data. Every policy change was a database change.
- **After**: Persona policies as code in OPA. Rego policies in Git with code review workflow. VPD still enforcing as defense in depth. Application code unchanged. Shadow mode validation against the live VPD before any cutover. Decision logs structured for NIST SP 800-171 AC, AU, IA, and SC families.

## Results

### Delivered as scoped, rated accordingly

The engagement closed with strong recorded performance across every CPARS dimension and a stronger authorization foundation for CWMS data, without any disruption to the system already in use.

- **Exceptional**: CPARS rating in primary dimensions
- **Very Good**: CPARS rating across remaining dimensions
- **Ahead**: Delivered ahead of the agreed schedule
- **Zero**: Disruption to the legacy system in active use

## Beyond the Scope of Work

The team contributed additional capability beyond the contracted scope, including documentation, integration patterns, and design artifacts that strengthened the foundation for future enhancements and reduced downstream risk to the program office.

## What This Demonstrates

### Evolving mission systems without disrupting active operations

The CWMS engagement is the operational precedent for how we approach federal ICAM and access management modernization generally: clear analysis of dependencies, layered architecture that respects what already exists, incremental rollout, and direct program office coordination at every step.