Coalition identity management: federated authentication across NATO and partner networks

When a French liaison officer connects to a shared coalition command system, no single organization owns her identity. Her credentials were issued by Direction Interarmees des Reseaux d'Infrastructure et des Systemes d'Information (DIRISI), her clearance was adjudicated under French national security policy, and her roles were assigned by her chain of command in Paris. The coalition application she is connecting to runs on infrastructure managed by a partner nation and trusts none of the above by default. Bridging this gap reliably, securely, and without requiring manual provisioning of thousands of transient coalition accounts is the problem that coalition identity management solves. This article examines the protocols, PKI structures, attribute schemas, and policy machinery that make coalition interoperability possible at the identity layer.

The identity problem in coalition operations

Coalition operations assemble personnel from multiple sovereign nations on timescales measured in days. A standing joint task force may include contributors from a dozen nations, each operating under its own identity governance regime, using its own directory infrastructure, and issuing credentials under its own national PKI hierarchy. Before federated identity solutions existed, the standard approach was manual provisioning: liaison staff at each nation's system boundary would create local accounts for incoming coalition users, assign permissions manually, and deactivate those accounts when the user rotated out. This process was slow, error-prone, inconsistently documented, and created persistent orphaned accounts that remained active long after the personnel they represented had left the coalition.

The fundamental requirement is that authentication and authorization must remain under sovereign control while enabling access across national boundaries. No nation accepts a centralized coalition identity authority that could be captured, compromised, or politically leveraged by another member. The architecture therefore cannot rely on a single identity store that all nations federate into. Instead, it must treat each nation's identity provider as a peer, establishing bilateral or multilateral trust relationships between them without surrendering national control over the credentials themselves. This is the defining constraint that makes coalition identity management architecturally distinct from enterprise single sign-on.

The practical consequence is that every identity transaction across a coalition boundary involves at least three parties: the user's home identity provider, the resource-owning relying party at the partner nation, and the trust framework that both sides have agreed to operate under. As described in the Federated Mission Networking implementation guide, this trust framework is documented in federation agreements that specify which attributes will be exchanged, what claim formats are expected, and how access decisions will be made at the boundary.

Federation protocols: SAML 2.0, OAuth 2.0, and OIDC for defense environments

Security Assertion Markup Language 2.0 (SAML 2.0) remains the dominant protocol for identity federation in defense and government environments. Its maturity, broad implementation across enterprise identity platforms (Microsoft ADFS, Shibboleth, Ping Identity), and its XML-signature-based assertion model align well with existing PKI infrastructure. A SAML assertion is a signed XML document that carries the user's identity claims and is issued by the home IdP after the user authenticates locally. The relying party validates the assertion's signature against the IdP's signing certificate, checks the audience restriction (confirming the assertion was issued for this specific RP), and verifies the assertion timestamp to prevent replay attacks. Because the assertion is signed at issuance, the RP does not need a direct connection to the IdP at validation time, which is valuable in occasionally disconnected coalition environments.

OAuth 2.0 and OpenID Connect (OIDC) are increasingly present in coalition architectures as newer systems adopt REST-native APIs rather than the SOAP-oriented patterns that SAML was designed for. OIDC extends OAuth 2.0 with a standardized ID token (a JSON Web Token) that carries identity claims, while OAuth 2.0 access tokens are used to authorize API calls on behalf of the authenticated user. The shorter token format and HTTP-native flows make OIDC preferable for mobile and web applications. For coalition use, OIDC requires that the authorization server at the home nation be reachable from the partner's network at token issuance time, which imposes a connectivity dependency that SAML's offline assertion model avoids. Many coalition deployments therefore run SAML for primary authentication and issue short-lived OIDC tokens locally at the partner's boundary, effectively translating an incoming SAML assertion into an OIDC session scoped to the partner's application ecosystem.

Both protocols require careful hardening for defense environments. Assertion encryption (not just signing) is mandatory when assertions traverse network boundaries, because a signed but unencrypted SAML assertion exposes the user's clearance level, nationality, and role assignments to any network observer. TLS 1.3 with mutual authentication should protect all federation endpoints. Clock synchronization across all IdP and RP infrastructure is a silent dependency: SAML timestamp validation windows are typically set to five minutes, and a clock drift exceeding this window causes valid assertions to fail, breaking access for affected users without any obvious error other than an authentication timeout.

PKI cross-certification: bridging national certificate authorities

Identity federation assertions are only as trustworthy as the signing keys behind them. Every SAML IdP signs its assertions with a certificate issued under a certificate authority hierarchy. For a partner nation's RP to trust an incoming assertion, it must trust the CA that issued the signing certificate. In a domestic single-organization deployment, this is straightforward: one CA issues certificates to all relying parties and identity providers. In a coalition, each nation operates its own CA hierarchy, issuing certificates under national policy frameworks that other nations' systems do not recognize by default.

Cross-certification resolves this by creating explicit trust links between national CA hierarchies. In its simplest bilateral form, Nation A's CA issues a cross-certificate for Nation B's CA (and vice versa). A relying party in Nation A that trusts its own CA hierarchy transitively trusts certificates issued under Nation B's CA. The cross-certificate specifies the depth of the trust path and can include policy constraints that limit which certificate uses are trusted (e.g., trusting Nation B certificates only for digital signature verification, not for key encipherment). In NATO, the NATO Public Key Infrastructure operates a bridge CA that cross-certifies participant nations' CAs, allowing a single bridge relationship to propagate trust across all connected national hierarchies rather than requiring every nation pair to establish a direct bilateral cross-certification.

Certificate policy identifiers (OIDs in the certificate extensions) are the mechanism by which relying parties apply nation-specific trust decisions. A coalition RP may be configured to accept certificates from all cross-certified national CAs for general authentication purposes but require a specific policy OID (indicating a hardware-token-based credential or a specific assurance level) before permitting access to classified-releasable resources. This two-tier policy model - broad authentication trust, narrow authorization trust - avoids the operational problem of changing the cross-certification agreement every time a new resource category requires higher assurance, since the fine-grained rules live in the RP's local policy rather than in the CA infrastructure.

Role mapping across heterogeneous coalition directories

Even when authentication succeeds across a federation boundary, the authorization decision at the partner's system requires translating the incoming identity claims into something the local access control system understands. A French officer's rank of Lieutenant-Colonel, asserted in French military LDAP attribute format, is meaningless to a British C2 system whose access control lists are built around British rank grades and role codes. Role mapping is the process of establishing equivalences between the attribute schemas of different national directories so that incoming assertions can be converted to locally actionable access decisions.

The translation layer is typically implemented as a claims transformation rule set in the partner's RP or identity broker. Rules take the form of conditional mappings: if the incoming assertion carries a nationality attribute of "FRA" and a rank code in the range corresponding to OF-4 to OF-5 in NATO's STANAG rank scale, map the user to the local group "coalition-senior-officer". The STANAG rank scale is the lingua franca that makes this possible: it provides a common numeric identifier for each rank across all allied nations, allowing role mapping rules to be written against the neutral STANAG code rather than each nation's native rank label. Nations that contribute personnel to a coalition are responsible for including the STANAG rank equivalent in their SAML assertions, a requirement that should be verified during federation testing.

Organizational role assignments present a more complex mapping challenge because no NATO standard provides the equivalent of STANAG rank codes for functional roles. A user assigned the role "intelligence analyst" in Nation A's directory may need to be mapped to different local roles depending on which of the partner's systems they are accessing and what the current coalition rules of engagement specify for that role's access level. This requires that role mapping rules be maintained as a living document, updated through the coalition's identity management coordination process as new systems are federated and as operational requirements change. The coalition data sharing challenges that arise from incompatible data models are most acute precisely at this attribute translation boundary.

Attribute-based access control for releasability enforcement

Role-based access control (RBAC) assigns permissions to roles and roles to users. For coalition systems, this model is insufficient because access decisions depend on dimensions that roles alone cannot capture. A document marked REL TO USA, GBR, CAN, AUS, NZL (releasable to the Five Eyes nations) must be accessible to a Canadian officer at the SECRET level but not to a French officer at the equivalent level, regardless of whether both hold identical functional roles. Releasability is a property of the resource, not of the user's role, and enforcing it correctly requires evaluating the user's nationality, clearance, need-to-know, and the resource's classification label simultaneously.

Attribute-based access control (ABAC) handles this naturally. An ABAC policy is a logical rule that evaluates subject attributes (nationality, clearance, role, assignment), resource attributes (classification level, releasability caveats, handling instructions), and environmental attributes (network classification level, time of access) against an explicit policy statement. A policy for the document above might read: permit access if subject.nationality in [USA, GBR, CAN, AUS, NZL] AND subject.clearance >= SECRET AND resource.classification <= SECRET AND resource.releasability contains subject.nationality. This rule is authorable, auditable, and independent of any specific nation's role taxonomy. The policy engine evaluates it at access time against the claims extracted from the SAML assertion and the resource's metadata.

The eXtensible Access Control Markup Language (XACML) is the most mature standard for expressing and evaluating ABAC policies in defense environments. A XACML Policy Decision Point (PDP) receives an authorization request containing subject, resource, and environment attributes, evaluates it against the loaded policy set, and returns a permit or deny decision. The Policy Enforcement Point (PEP) in the application intercepts every resource access, constructs the authorization request, calls the PDP, and enforces the decision. Separating the PEP from the PDP allows the policy to be updated, versioned, and audited independently of the application code - a critical property when releasability rules change as the operational situation evolves.

Relying party configuration and metadata management at scale

A coalition of twelve nations, each operating ten to thirty federated applications, produces a metadata management problem with a non-trivial operational surface. Every relying party must have current, valid metadata for every IdP it accepts assertions from. Every IdP must have registered every RP it may issue assertions to. When a nation rotates its IdP signing certificate (which should happen at least annually and whenever compromise is suspected), every RP that accepts that nation's assertions must be updated with the new certificate before the old one expires. Doing this manually across hundreds of bilateral registrations is operationally unsustainable and produces access outages when updates lag certificate rotations.

The solution is a federation metadata registry: a centrally published, signed XML document that lists the metadata for all registered IdPs and RPs in the coalition federation. Each participant fetches the registry on a defined schedule (typically every 4-24 hours), extracts the entries relevant to their trust configuration, and updates their local identity platform. The registry itself is signed by a coalition registry authority key, and each participant validates that signature before applying any updates - preventing a compromised intermediate network node from injecting false metadata to redirect authentication flows. SAML metadata registries following the SAML V2.0 Metadata Extensions for Registration and Publication specification provide the technical framework for this; NATO's Federated Mission Networking programme has documented the operational processes around it.

Metadata consumers should be configured to fail closed on metadata fetch failure: if the registry is unreachable and a cached copy has expired, the system should deny authentication attempts from affected IdPs rather than continuing to rely on potentially stale certificates. The operational tradeoff between availability and security here is explicit and should be codified in the federation agreement - defining how long cached metadata can be used before it is considered expired, and what the fallback behavior is when the registry is unreachable during combat operations where network connectivity may be intermittent.

Incident response: revoking access across a federated coalition rapidly

The revocation problem in a federated coalition is harder than in a single-organization PKI because the revocation action must propagate across sovereign boundaries to systems that the originating nation does not control. When a coalition user's credentials are compromised - through theft, coercion, or a security incident at the home nation - every relying party across all partner nations that may have accepted assertions from that user must be informed and must enforce the revocation. The time between incident declaration and universal enforcement of revocation is the exposure window during which the compromised credential remains usable.

Short assertion lifetimes are the most effective first-order control. A SAML assertion with a 30-minute validity window expires before a compromised credential can be extensively exploited in most scenarios, without requiring any out-of-band revocation notification to reach the relying party. The cost is that the user must re-authenticate every 30 minutes, which is manageable with seamless SSO re-authentication (where the IdP silently issues a new assertion without prompting the user) but becomes operationally disruptive if the IdP is unreachable during the re-authentication window. Setting assertion lifetime requires balancing this tradeoff against the expected connectivity profile of the coalition network.

For PKI certificate revocation, Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) are the two mechanisms available. CRL-based revocation publishes a signed list of revoked certificate serial numbers that relying parties fetch periodically; the revocation latency is bounded by the CRL refresh interval, typically 24 hours in national PKI practice but configurable to 1-4 hours for high-urgency coalition scenarios. OCSP provides real-time revocation status but requires the OCSP responder to be reachable at authentication time - the same connectivity dependency problem as OIDC. A layered approach is appropriate: short-lived SAML assertions as the primary control, frequent CRL fetches as the certificate-level safety net, and OCSP stapling at TLS layer for applications where real-time certificate status is required. Out-of-band notification procedures - documented contact lists, predefined message formats, and tested escalation paths across the coalition - complete the incident response capability that no technical protocol can fully automate.