Skip to main content
Version: Next

SAML Authentication with ADFS

This guide explains how to configure Cortex Archive to authenticate users using SAML 2.0 with Active Directory Federation Services (ADFS).

The process consists of:

  1. Configuring Cortex Archive to trust your Identity Provider (IdP)
  2. Configuring ADFS to trust Cortex Archive as a relying party
  3. Validating identity claims and login behavior

Prerequisites

Before starting, ensure the following are available:

  • An ADFS server connected to your Active Directory domain
  • A valid, unexpired certificate for SAML signing and encryption
    • The PFX (with private key) must be available on the Cortex Archive server
    • The public certificate only must be available on the ADFS server
  • Administrative access to both the Cortex Archive host and the ADFS management console

Step 1 - Configure Cortex Archive to Use SAML

Enable SAML authentication

In appsettings.json, set the authentication type to saml:

{
"Authentication": {
"Type": "saml"
}
}

Configure SAML identity provider settings

Under the Authentication:Saml block, configure the following:

  • IdPMetadataUri - the URL to your ADFS federation metadata. For most environments:

    https://YOUR-ADFS-SERVER/FederationMetadata/2007-06/FederationMetadata.xml
  • PublicUri - the externally accessible URL users use to reach Cortex Archive (for example: https://archive.company.com)

  • CertificateFile (recommended) - full path to the .pfx certificate file containing the private key

  • CertificatePassword - the password used when exporting the certificate

Example configuration:

{
"Authentication": {
"Type": "saml",
"Saml": {
"IdPMetadataUri": "https://adfs.company.com/FederationMetadata/2007-06/FederationMetadata.xml",
"PublicUri": "https://archive.company.com",
"CertificateFile": "C:\\certs\\saml-signing.pfx",
"CertificatePassword": "your_certificate_password"
}
}
}

Step 2 - Configure ADFS as a Relying Party

On the ADFS server:

  1. Create a new Relying Party Trust using manual configuration.
  2. When prompted:
    • Entity ID / Relying Party Identifier - use the same value as PublicUri
    • Signing certificate - upload the public certificate only (no private key)
  3. Accept defaults unless your organization has specific security requirements.

Step 3 - Configure Claims Mapping

Cortex Archive needs a stable identifier to match incoming users to existing accounts.

At minimum, map:

  • LDAP attribute: SAM-Account-Name
  • Outgoing claim type: Name ID

This allows Cortex Archive to match users by their Windows username. Additional claims may be mapped depending on your setup (email-based lookup, custom identifiers, etc.).


Optional Configuration Settings

Most environments work with the default configuration. If authentication fails or behaves unexpectedly, the following settings may help.

Settings are listed in Block:SubBlock:Setting format:

  • In appsettings.json - use nested JSON blocks
  • In environment variables - replace : with __ (for example, Authentication__Saml__ForceAuthn)
SettingDescription
Authentication:LookUpBySet to Email if users should be identified by email address instead of username
Authentication:IdentifierClaimThe name of the claim sent by ADFS that identifies the user (for example: emailAddress or a URI-style claim)
Authentication:Saml:CertificateValidationModeSet to None to disable certificate validation - not recommended for production
Authentication:Saml:RevocationModeControls certificate revocation checking behavior
Authentication:Saml:ForceAuthnForces credential entry at the IdP on every login, even if the user has an active session

Troubleshooting

If login fails, users are redirected unexpectedly, or claims are not recognised, see:

SAML with ADFS Troubleshooting

A video walkthrough of the full ADFS configuration is also available on that page.