Role-Based Access Control in Defense C2 Systems: Design and Implementation

Access control in defense C2 software is not a feature added at the end of development. It is a foundational architectural decision that determines who can see which data, who can issue which commands, and how those decisions are enforced at every layer of the system — from API endpoints to database queries to WebSocket subscriptions. Getting it wrong means either exposing classified data to unauthorized users or locking out operators who need real-time situational awareness to make time-critical decisions.

Standard role-based access control (RBAC), as implemented in commercial identity providers like Keycloak or Azure AD, covers role-to-permission mapping adequately for enterprise software. Defense C2 systems require an additional dimension: classification levels and compartments. A user may be authenticated and hold the correct role (e.g., "operator") but still be denied access to a specific track because that track is marked with a classification or compartment the user does not hold clearance for. This is the need-to-know principle in technical form.

RBAC vs ABAC: Which Model Fits Defense C2

Pure RBAC assigns permissions to roles and roles to users. A "Battalion S2" role grants access to intelligence overlays; a "Logistics Officer" role grants access to supply chain data. This model is simple to implement and audit, but it cannot express fine-grained data-level restrictions without role explosion — creating a separate role for every possible data classification combination.

Attribute-Based Access Control (ABAC) evaluates access decisions based on attributes of the subject (user), the resource (data object), the action, and the environment (time, network context). In an ABAC model, access to a track is granted if: the user's clearance level is greater than or equal to the track's classification level AND the user holds all compartment tags associated with the track AND the user's current terminal is on an approved network segment.

In practice, defense C2 systems use a hybrid: RBAC for coarse-grained role enforcement (who can access which application module) and ABAC for fine-grained data filtering (which records within a module a user can see). The RBAC layer is enforced at authentication time via JWT claims; the ABAC layer is enforced at query time by the data layer applying row-level security based on the user's attribute set.

Classification Levels and Compartments

NATO classification levels in ascending order: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET. Most tactical C2 systems operate at SECRET or below, with some systems handling TOP SECRET / SCI data in separate enclaves. The classification level of a data object is the minimum clearance level required to access it.

Compartments are orthogonal to classification levels. A user cleared to SECRET may not hold the SIGINT or HUMINT compartment, even at SECRET level. A track derived from a SIGINT sensor is tagged with the SIGINT compartment; only users holding that compartment see the track in the COP, regardless of their overall clearance level. In software, compartments are implemented as a set of string tags on both the data record and the user's attribute set; access is granted only when the data record's compartment set is a subset of the user's compartment set.

Need-to-know adds a third dimension: even a user with the correct clearance level and compartment membership may be restricted from accessing data unrelated to their current mission assignment. This is harder to enforce programmatically and is often implemented as a combination of ABAC policy and manual data custodian controls.

JWT Claim Structure for Defense C2

JSON Web Tokens carry the user's identity and attribute claims between the identity provider and C2 application services. A defense-oriented JWT payload structure:

{
  "sub": "user-uuid-1234",
  "name": "Cpt. A. Smith",
  "roles": ["operator", "s2-officer"],
  "clearance": "SECRET",
  "compartments": ["SIGINT", "HUMINT"],
  "unit": "1-32-IN",
  "network_segment": "SIPRNET",
  "iat": 1746960000,
  "exp": 1746963600,
  "jti": "unique-token-id"
}

The clearance claim carries the user's clearance level as a string that maps to a numeric value in the policy engine (UNCLASSIFIED=0, RESTRICTED=1, CONFIDENTIAL=2, SECRET=3, TOP SECRET=4). The compartments claim is an array of compartment strings. The network_segment claim carries the network context — SIPRNET, NIPRNET, or a mission-specific network identifier — enabling environment-based access decisions.

Token validity periods for defense systems are shorter than commercial norms: 60-minute access tokens with refresh token rotation. Each token refresh re-validates against the identity provider's current attribute store, ensuring that revoked clearances take effect within one refresh cycle.

Policy Enforcement Points

In a microservices C2 architecture, access control must be enforced at multiple layers — not just at the API gateway. A defense C2 system typically has three policy enforcement points:

API Gateway (coarse RBAC). Validates JWT signature and expiry. Rejects requests with invalid tokens. Routes requests to appropriate service based on role claims. Does not make data-level access decisions.

Service Layer (ABAC policy evaluation). Each service that handles classified data has an embedded policy decision point. Before returning a data object, the service evaluates: user clearance >= data classification level AND user compartments superset of data compartments. Objects that fail this check are filtered from the response, not returned with a 403 error — the existence of classified records is itself often classified.

Database Layer (row-level security). PostgreSQL row-level security (RLS) policies enforce data-level restrictions at the database itself, providing defense-in-depth against application logic errors. Even if a service has a bug in its policy evaluation, the database layer prevents unfiltered data from reaching the application.

Bell-LaPadula Multi-Level Security Model

The Bell-LaPadula (BLP) model formalizes access control for classified information with two primary rules. The Simple Security Property (no read up): a subject at classification level L cannot read an object at classification level L' where L' > L. The Star Property (no write down): a subject at classification level L cannot write to an object at classification level L' where L' < L — preventing a cleared user from copying classified data into an unclassified record.

In practice, the no-write-down rule is the harder one to enforce in web application architectures. An operator with SECRET clearance working in a C2 application could, through application logic flaws, copy SECRET track data into an UNCLASSIFIED report. Enforcement requires that write operations explicitly set the classification level of the target record to the maximum of the source data's classification level, and that this logic be enforced at the service layer, not left to the operator.

IAM Provider Integration

Keycloak is the most commonly used open-source identity provider in defense C2 programs due to its support for LDAP/Active Directory federation, fine-grained authorization policies, and on-premises deployment without cloud dependency. It can be deployed air-gapped, which is a requirement for classified network deployments.

Keycloak's Authorization Services support ABAC policy evaluation natively. Policies are defined as JavaScript-based rules or using the built-in JSON policy language. In a typical C2 integration, Keycloak issues JWTs containing the user's clearance and compartment claims, derived from Active Directory group membership synchronized from the classified network's directory service.

Audit Trails and SIEM Integration

Every access decision — both grants and denials — must be logged with sufficient detail for security audit and incident response. A defense C2 audit log entry includes: timestamp, user identifier, user clearance level, action attempted, resource identifier, resource classification level, decision (GRANT/DENY), and the policy rule that produced the decision.

Audit logs are forwarded to a Security Information and Event Management (SIEM) system — IBM QRadar or Splunk Enterprise Security in most NATO program contexts — for real-time anomaly detection. A user accessing an unusual number of records outside their normal operational area, or a sequence of denied access attempts followed by successful access, triggers an alert for security review.