Overview#
When a national cybersecurity agency deploys Argus for government CERT operations, requiring each analyst to create and manage a separate Argus account is both an administrative burden and a security liability. SAML 2.0 federation solves this: government employees authenticate through the national government IdP they already use every day, and the assertion arrives at Argus pre-validated. No Argus-local password. No parallel account management. No additional credential for an attacker to target.
SAML 2.0 is the dominant enterprise and government authentication federation standard, underpinning SSO across health systems, defence networks, tax authorities, and national digital identity frameworks (including eIDAS-linked schemes in EU member states). Argus implements SAML 2.0 SP (Service Provider) functionality and maintains a registry of trusted IdP configurations. Operators from partner agencies and customer organisations authenticate to Argus using their existing enterprise credentials.
Open Standards#
- OASIS SAML 2.0: The core federation protocol implemented end-to-end; Argus acts as a SAML 2.0 Service Provider, issuing AuthnRequest messages, consuming signed SAMLResponse assertions at the Assertion Consumer Service, and supporting Single Logout (SLO) initiated by the Identity Provider.
- OASIS SAML 2.0 Metadata: IdP configuration (SSO endpoint URLs, X.509 signing certificates, entity IDs) is sourced from published SAML metadata documents, enabling automated certificate rotation without manual operator intervention.
- X.509 / PKIX (ITU-T X.509, RFC 5280): Every SAML assertion signature is validated against the X.509 certificate registered for the issuing IdP; certificate expiry is tracked and surfaced to operators to prevent authentication failures at renewal time.
- XML Signature Syntax and Processing (W3C XMLDSIG, RFC 3275): Assertion integrity and authenticity depend on XML digital signatures; Argus verifies the signature on each inbound SAMLResponse before accepting any identity claim. The verifier requires the signature to bind to the exact assertion being consumed (or to the signed response envelope that contains it) and rejects documents carrying multiple signatures, defeating signature-wrapping forgeries.
- eIDAS Regulation (EU 910/2014): National government IdP integrations in EU member states may present eIDAS-linked credentials; the module is designed to accept assertions from eIDAS-notified schemes used in national CERT and NIS2-mandated deployments.
- SCIM 2.0 (RFC 7642/7643/7644): SAML handles identity assertion while SCIM handles complementary user lifecycle management (provisioning and deprovisioning), with both standards operating in concert within a complete federated identity architecture.
- OAuth 2.0 and JWT Bearer Token: Token-based authentication protects typed, auditable read and write workflows across the platform.
Key Features#
Identity Provider Registry#
Each trusted SAML IdP is registered with entity ID, metadata URL, and display name. Argus fetches IdP metadata (containing the X.509 signing certificate and SSO endpoint URLs) via the metadata refresh workflow and persists it locally. Metadata is periodically re-fetched to capture certificate rotations and endpoint changes before they cause authentication failures.
Metadata-Driven Configuration#
Rather than manually configuring signing certificates and endpoint URLs, all IdP parameters are derived from the published metadata document. IdP certificate rotations are handled automatically: the next metadata fetch picks up the new certificate before the old one expires.
Entity ID and Issuer Validation#
Every SAML assertion is validated against the registered entity ID for the issuing IdP. Assertions from unregistered entity IDs are rejected outright. This prevents SAML response injection attacks where an attacker substitutes an assertion from a weaker or attacker-controlled IdP.
Signature-Wrapping Defence#
Verification of an inbound SAMLResponse goes beyond checking that a valid signature is present somewhere in the document. The signature must bind to the exact assertion Argus consumes, or to the signed response envelope that contains it, and any document carrying multiple signatures is rejected outright. This defeats signature-wrapping attacks, in which an attacker splices a forged assertion into a legitimately signed document in the hope that the verifier checks one assertion and consumes another.
Audience and Expiry Enforcement#
In production deployments, an assertion must name Argus as its intended audience and must carry an upper time bound. Assertions missing either are refused: an assertion without an audience restriction could be replayed to any relying party, and one without an expiry could be replayed indefinitely. Non-production environments log a warning instead of failing, keeping local identity-provider fixtures usable during integration work.
Attribute Mapping#
SAML attributes in the assertion (typically email address, display name, organisation, and group memberships) are mapped to Argus user profile fields and role assignments. Attribute mapping is configurable per IdP, accommodating different naming conventions across partner organisations.
Multi-IdP Support for Allied Operations#
Operations involving multiple nations or organisations naturally involve multiple IdPs. Argus's multi-IdP registry allows operators from allied nation A to authenticate via their national IdP while operators from allied nation B use their own, within the same Argus deployment serving the combined operation.
Tenant-Scoped Federation Administration#
Administrative views of federation configuration are strictly tenant-scoped. Listing and inspecting registered SAML IdPs, and reading or updating a tenant's eIDAS trust material (identity-provider metadata, signing certificates, and trust anchors), is available only to platform administrators and to each tenant's own administrators for their own tenant. The caller's tenant is derived server-side and requests fail closed when tenant context is missing, so one tenant's administrators can never read or overwrite another tenant's regulated federation material. Authorisation failures surface as clear access-denied responses rather than being masked as generic service errors.
Session Management#
SAML-authenticated sessions respect IdP-issued session validity periods and support SAML Single Logout (SLO). When an IdP terminates a user session, SLO propagates the termination to Argus, preventing use of SAML sessions after the IdP has revoked them.
Use Cases#
- National SOC to Government IdP Integration: A national cybersecurity agency running Argus for government CERT functions authenticates all staff via the national government IdP, with eIDAS-linked credentials in EU member states providing hardware-backed SSO and no Argus-local password management
- Allied Exercise Federated Access: During NATO cyber exercises, operators from member states authenticate through their national defence IdP. Argus consumes the assertion and automatically maps to appropriate exercise roles based on SAML group attributes
- Defence Contractor Access: Prime and sub-contractors use their company IdP rather than manually provisioned accounts, with project-duration scoping managed at the IdP group level
- NIS2 Compliance for Government IdP Mandates: Several NIS2 implementations require government contractors handling sensitive information to authenticate via national government identity schemes; SAML federation enables compliance while maintaining SSO usability
- Delegated Federation Administration in Multi-Tenant Estates: A shared Argus deployment serving several agencies lets each tenant's administrators manage their own IdP registrations and eIDAS trust material, while the regulated federation artefacts of every other tenant remain out of reach
Integration#
Authenticated read, write, and reporting workflows are available through organisation-scoped integration contracts with audit logging.
Works alongside Keycloak IDM (which can act as a SAML IdP or broker external SAML IdPs), Zitadel IAM (OIDC alternative for cloud-native IdPs), and SCIM Provisioning (which complements SAML authentication with automated user lifecycle management). SAML handles identity assertion; SCIM handles account creation and removal.
Last Reviewed: 2026-07-16 Last Updated: 2026-07-16