Single Sign-On and Federation
What this domain tests
Single Sign-On and Federation tests SAML identity provider configuration, Fortinet Single Sign-On with collector and agent roles, and RADIUS-based SSO. You should know which component authenticates, which component trusts an assertion or logon event, and which attributes drive authorization.
SAML federation
FortiAuthenticator commonly acts as a SAML identity provider. The service provider, such as FortiGate SSL VPN or a third-party application, trusts FortiAuthenticator assertions. Metadata exchange supplies the entity ID, assertion consumer service URL, and signing certificate. Attribute statements carry the username and often group information. Clock skew between IdP and SP breaks assertion validation.
FSSO
Fortinet Single Sign-On collects Windows logon information. A DC Agent on domain controllers reports logons to a Collector Agent, which FortiGate queries. A Terminal Server Agent handles multi-user terminal servers where one IP maps to many users. FortiAuthenticator can act as the Collector Agent. Group filters limit which users are reported, so a missing group in the filter looks like a missing login.
RADIUS SSO
RADIUS accounting messages can create user-to-IP session mappings for SSO. This depends on the network device sending accounting records; authentication alone may not provide the session information FortiGate needs.
Worked example
FortiGate SSL VPN uses FortiAuthenticator as a SAML IdP. On FortiAuthenticator, create the SAML IdP and define the FortiGate as a service provider with its entity ID and ACS URL. Export metadata or certificates, import them on FortiGate, and map the username and group attributes. Reasoning: FortiAuthenticator authenticates the user and signs the assertion, but FortiGate authorizes based on the attributes it receives, so attribute names and group values must match exactly.
Traps that cost marks
- Metadata mismatch: entity ID, ACS URL, or signing certificate differs between IdP and SP.
- SAML assertion attributes use names the SP does not expect, so authentication succeeds but authorization fails.
- FSSO group filters exclude the user, producing an empty or missing login record.
- DC Agent or Collector Agent connectivity fails, but the issue is blamed on FortiGate policy.
- Time skew or expired certificates invalidate assertions even when credentials are correct.