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:
- Configuring Cortex Archive to trust your Identity Provider (IdP)
- Configuring ADFS to trust Cortex Archive as a relying party
- 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.pfxcertificate 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:
- Create a new Relying Party Trust using manual configuration.
- When prompted:
- Entity ID / Relying Party Identifier - use the same value as
PublicUri - Signing certificate - upload the public certificate only (no private key)
- Entity ID / Relying Party Identifier - use the same value as
- 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)
| Setting | Description |
|---|---|
Authentication:LookUpBy | Set to Email if users should be identified by email address instead of username |
Authentication:IdentifierClaim | The name of the claim sent by ADFS that identifies the user (for example: emailAddress or a URI-style claim) |
Authentication:Saml:CertificateValidationMode | Set to None to disable certificate validation - not recommended for production |
Authentication:Saml:RevocationMode | Controls certificate revocation checking behavior |
Authentication:Saml:ForceAuthn | Forces 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.