ADFS Single Sign-On
Microsoft·AE_ADFS_SSO_ConfigurationGuide
Overview
The ADFS SSO connector configures AlertEnterprise Guardian to federate user authentication to Microsoft Active Directory Federation Services (ADFS) via SAML 2.0. This is the SSO connector pattern — AE doesn't provision into ADFS or reconcile from it; it configures Guardian as a SAML Service Provider (SP) and ADFS as the Identity Provider (IdP). The user authenticates against ADFS (which in turn authenticates against on-prem Active Directory) and ADFS asserts the identity to AE Guardian.
Critical operational note: the ADFS user must be synced into the Alert Enterprise application database and have AE-side access assigned before SSO will work. ADFS only assertss identity; AE Guardian still needs a corresponding identity record in its own database. This is typically handled by running an active-directory reconciliation in advance.
Architecture: End User → AE Guardian (SAML SP) → ADFS (SAML IdP) → on-prem Active Directory. The ADFS configuration creates a Relying Party Trust for AE Guardian (using AE-provided metadata XML), with claim rules that emit the user's E-Mail-Address as Name ID + a tenant claim (tenant = alert).
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
1 method supported
AE Guardian acts as the SAML Service Provider. ADFS acts as the SAML Identity Provider. The flow:
1. User accesses AE Guardian URL 2. AE Guardian redirects browser to ADFS for authentication 3. User authenticates against ADFS (which validates against on-prem Active Directory) 4. ADFS posts a SAML response back to AE Guardian containing Name ID (user's email) + tenant claim 5. AE Guardian looks up the user in its own database by Name ID and logs them in
AE provides metadata XML to the ADFS admin during setup; the admin imports it via Add Relying Party Trust → Import data about the relying party from a file.
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
ADFS deployment trusting on-prem Active Directory
customerAn operational Microsoft ADFS deployment configured as the federation gateway for the customer's on-prem AD.
AE-generated metadata XML imported as Relying Party Trust
jointThe AE Support team generates metadata XML describing AE Guardian as a SAML SP. The customer's ADFS admin imports this XML into ADFS via Trust Relationships → Relying Party Trusts → Add Relying Party Trust → Import data about the relying party from a file.
Claim rules configured on the Relying Party Trust
customerThree claim rules must be configured on the AE Relying Party Trust:
1. Send LDAP Attributes as Claims — LDAP Attribute: E-Mail-Addresses → Outgoing Claim Type: E-Mail Address
2. Transform an Incoming Claim — E-Mail Address → Name ID (format: Email), Pass through all claim values
3. Send Claims Using a Custom Rule — => issue(Type = "tenant", Value = "alert"); (confirm tenant value with AE Support)
User records pre-synced into AE Guardian database
aeADFS users must exist in AE Guardian's database before SSO will work. Typically this is achieved by running the active-directory connector to reconcile users from AD into AE, then enabling SSO. Without pre-synced records, SAML assertions arrive at AE for users that don't exist in AE — authentication fails.
Known limitations
Documented constraints to set customer expectations before deployment.
Authentication only — no provisioning or reconciliation
informationalThis connector configures SSO. It does not provision users into ADFS or reconcile identity data from ADFS. For identity-data sync use the active-directory connector against the underlying on-prem AD.
IAM specifics
- OIDC
- no
- SAML
- yes
- SCIM
- no
- JIT provisioning
- no
- Group sync mode
- not-supported
- Source of record
- No
MFA is configurable on the ADFS Relying Party Trust (Configure Multi-factor Authentication screen during setup). Default for AE-configured trust is "I do not want to configure multi-factor authentication for this relying party trust" — customers requiring MFA enable it on the ADFS side.
Single SAML attribute: E-Mail-Address (from AD's E-Mail-Addresses) transformed into SAML Name ID with format Email. Plus a custom "tenant" claim set to "alert" by default.
- src/connectors/adfs-sso/source.pdf — Full configuration guide — 15 pages, updated 2025-08-22