SAML IdP

Security Assertion Markup Language (SAML) is used for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP), such as Google Apps, Office 365, and Salesforce. The FortiAuthenticator can be configured as an IdP, providing trust relationship authentication for unauthenticated users trying to access an SP.

Realms can be selectively enabled while configuring the FortiAuthenticator as the IdP. When more than one realm is selected, a default realm can be chosen. New realms can be configured at Authentication > User Management > Realms.

SAML authentication on FortiAuthenticator can be set up in an SP-initiated or IdP-initiated configuration.

SAML SP-initiated authentication works as follows:

1. A user attempts to access an SP, for example Google, using a browser.
2. The SPs web server requests the SAML assertions for its service from the browser.
3. Two possibilities:
   • The user's browser already has valid SAML assertions, so it sends them to the SPs web server. The web server uses them to grant or deny access to the service. SAML authentication stops here.
   • The user's browser doesn't have valid SAML assertions, so the SPs web server redirects the browser to the SAML IdP.
4. Two possibilities:
   • The user's browser is already authenticated with the IdP, go to step 5.
   • The user's browser is not yet authenticated with the IdP, so the IdP requests and validates the user's credentials. If successful, go to step 5. Otherwise, access is denied.
5. IdP provides SAML assertions for the SPs and redirects the user's browser back to the SPs web server. Go back to step 2.
   

SAML IdP-initiated authentication works as follows:

1. A user attempts to access the IdP login portal, resulting in one of two possibilities:
   • The user's browser is already authenticated by the IdP. Proceed to step 2.
   • The user's browser is not yet authenticated by the IdP, so the IdP requests and validates the user's credentials. If successful, go to step 2. Otherwise, access is denied.
2. The user is presented with an IdP portal landing page that includes a list of the SPs participating in IdP-initiated login. The user selects an SP.
3. IdP generates the SAML assertions for the browser and sends it to the SP.
4. The SP receives the assertions and authenticates the user, resulting in one of two possibilities:
   • The user is authorized, and the SP provides the requested resource to the user.
   • The user is not authorized, and access to the SP is denied.

When FIDO authentication is required, the end-user starts the login process on a username-only (Login Fido Page replacement message) login page same as for self-service portal, then proceeds through the subsequent authentication steps (FIDO/password validation) depending on the configuration.

This section contains the following topics:

• General
• Replacement messages
• Service providers