SAML authentication specification change after FortiGate update

Question

I’m seeking clarification and a possible solution regarding the recent change in FortiGate’s SAML authentication requirements.

The issue is described in the following Knowledge Base article:
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-SAML-Authentication-fails-after-firmware/ta-p/407859

According to the article, the new specification requires that both the Response and the Assertion within the SAML response be signed.
I understand that some IdPs, such as Microsoft Entra ID or Google IdP, support signing both elements as shown in the examples. However, what is the recommended workaround or solution if we are using an IdP that can sign only one of them?

I also have two questions regarding this policy:

1. Is this requirement a permanent change?

2. Could you share the rationale for requiring both the Response and the Assertion to be signed?

From my understanding, the Assertion is already a component of the Response, and signing the Response should inherently cover the Assertion as well.
Requiring both to be signed seems somewhat redundant — like locking a door twice with the same key — so I would appreciate your perspective on the necessity and reasonableness of this approach.

Thank you very much for your time and assistance.

AEK · Answer

The document you shared contains a piece of the response:

Note for Google IdP users: The Google implementation only signs either the assertion or reply based on the 'Signed reply' checkbox, but cannot sign both. If 'Signed reply' is unchecked, only the SAML Assertions are signed. If 'Signed reply' is checked, only the SAML Reply is signed. Both will fail since the FortiGate expects both Assertion AND Reply to be signed.

1. Is this requirement a permanent change?

I don't have the exact response for this case but as per my experience with Fortinet, 99% of security enhancement measures are permanent (still 1% possible as per my experience).

2. Why signing both?

I'm not SAML specialist but I think I've found a rational reason here:

In some cases a service provider may be comprised of separate service components, such as one responsible for generating the assertion and another responsible for applying additional metadata or context to the SAML response

Ref: https://security.stackexchange.com/questions/264749/in-a-saml-response-what-is-the-need-to-sign-both-things-the-complete-saml-respo

Hope it helps

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded