In my article Create an Azure AD Enterprise application using SAML protocol for SSO authentication I wrote about configuring SSO for various applications integrated with Entra ID. Today, I wanted to take a closer look at one specific application — FortiGate – and its configuration. Recently, there has been a noticeable increase in reported issues related to SAML authentication to FortiGate devices after upgrading the firmware to versions v7.2.12, v7.4.9 or v7.6.4.
While connecting to the FortiClient the users may experience the errors below:
When configuring SAML authentication for an application in Entra ID, you can choose what Entra ID signs before sending the authentication message to the service. You have two options: signing the SAML response and signing the SAML assertion. They may sound similar, but they work in different ways and can directly affect how an application processes the login request.
The first option, “Sign SAML Response,” means that Entra ID signs the entire response message. This response is the outer container that holds the user information. You can imagine it as a mystery bottle with a secret letter: the bottle itself is protected, but the document inside may not be individually secured. Some applications are perfectly fine with this approach because they validate the whole response as a single unit.
The second option, “Sign SAML Assertion,” focuses on the contents of the message. The assertion is the part that contains the user’s identity and claims. When you choose to sign the assertion, you are essentially signing the most important piece of information within the message. This is like signing the actual letter inside the mystery bottle so the application can confirm that the identity details are genuine. Many applications rely specifically on the assertion, so they expect this part to be signed.
These differences become important when working with FortiGate devices. In most cases, FortiGate does not only look at the full SAML response; it pays particular attention to the assertion inside. Because of this, FortiGate expects the SAML assertion to be signed. If it is not, the device will often refuse the authentication and display errors indicating that the signature is invalid or missing. This requirement has become even stricter in recent firmware versions. After updates to versions such as 7.2.12, 7.4.9 or 7.6.4, many administrators began noticing that configurations which previously worked suddenly started failing, even though nothing had been changed on the Entra ID side.
In practice, the key to avoiding these issues is to make sure that the option to sign the SAML assertion is enabled in Entra ID. Signing the entire response is usually optional and may or may not be necessary depending on the setup, but signing the assertion is the part that FortiGate depends on most.
I wouldn’t be myself if I didn’t show you a real, hands-on example of how to correctly configure SAML authentication for the latest versions of FortiGate. Here’s how to do it.
Go into your Azure Portal into Enterprise application and search for your FortiGate application. In the menu choose Signe sign-on
Go to SAML Certificates and edit this part
Under Signing Option select Sign SAML response and assertion
And that’s it. The configuration is not complicated so it’s worth knowing that such an option as SAML assertion exists just to avoid hours of troubleshooting especially after the upgrade of FortiGate is done.
Leave a Reply