[Developers]

Authentication: SAML 2.0 Federation

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

Category: ModulesLast Updated: Mar 18, 2026
modulescompliancegeospatial

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.
  • 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.
  • GraphQL (June 2018 specification): All management operations, querying registered providers, retrieving federation statistics, and synchronising provider metadata, are exposed via a typed GraphQL API requiring authenticated, organisation-scoped access.

Last Reviewed: 2026-03-18 Last Updated: 2026-04-14

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 fetchSamlProviderMetadata 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.

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.

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

Integration#

Available via GraphQL: samlProviders, samlStats (queries); syncSamlProvider (mutation). All operations require authentication and organisation scoping.

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.

Ready to Build?

Get started with our APIs or contact our integration team for support.