saml redirect from portal page broke after upgrading from JHF84 to JHF89

[Daniel_Kavan]

Hi All,

After upgrading from R81.20 JHF84 to JHF89 (in my lab) my redirect to my on prem IDP server broke.   Although I can connect to it ok from the command line.  If I revert back to JHF84 it works again.    I'm not sure how to troubleshoot this, any ideas are welcome.  We were actually planning on rolling it out this weekend.   There were some changes in JHF89 for SAML.  It looks like it tries to get to the idp server, fails and then fails to connect back to the portal.   It happens so fast, it's like it isn't even trying.  IOW, I'm not even getting to the inhouse IDP login page.

😞

This page isn’t working

portal.some.domain.com is currently unable to handle this request.

HTTP ERROR 500

NEW: This upgrade introduces three important SAML Authentication enhancements: Request Signing: Verifies authenticity of SAML requests. Assertion Decryption: Protects confidentiality of user attributes. Forced Re-authentication: Enables mandatory login for each session. Administrators gain more control over security policies, while the system becomes more adaptable to various high-security environments and Identity Provider requirements.

The Security Gateway may fail to resolve external Network Feeds whose URL contains a port number (such as "https://example.com:8080/feed.csv". Refer to sk182684.  

[PhoneBoy]

Wondering if one of these security enhancements is possibly causing issues with your IdP configuration.
There doesn't seem to be much in the way of troubleshooting information about SAML, though one suggestion in sk180543 is to install a SAML Tracer extension in your browser.
This will hopefully give you an idea of what's actually happening.

[Daniel_Kavan]

Thanks!  It seems like it has nothing to do with SAML since I can't even get to the website, but I will try it.  Looking at the httpd.log.0

PHP errors
[Tue Nov 05 11:18:16.713353 2024] [php7:notice] [pid 30702] [client ip:56661] [CAPTCHA] Captcha is not required
[Tue Nov 05 11:18:16.837429 2024] [php7:notice] [pid 14574] [client ip:56662] [absolute_portal_host] Receiving a NULL 'mab_portal_fqdn', referer: https://ip/Login/Login
[Tue Nov 05 11:18:17.100925 2024] [php7:notice] [pid 19567] [clientip:56666] [absolute_portal_host] Receiving a NULL 'mab_portal_fqdn', referer: IP/Login/Login
[Tue Nov 05 11:18:17.112959 2024] [php7:notice] [pid 19567] [client IP:56666] simplesamlphp ERR [TRb8098fb5] Configuration identity_provider definition., referer: https://IP/Login/Login
[Tue Nov 05 11:18:17.112991 2024] [php7:notice] [pid 19567] [client IP:56666] simplesamlphp ERR [TRb8098fb5] Configuration identity_provider definition., referer: https://IP/Login/Login
[Tue Nov 05 11:18:17.113005 2024] [php7:notice] [pid 19567] [client IP:56666] simplesamlphp ERR [TRb8098fb5] Configuration identity_provider definition., referer: https://IPurl/Login/Login

[Daniel_Kavan]

when it works (JHF84) the saml tracer shows a 302.  A 302 status code is an HTTP response code that indicates a requested resource has been temporarily moved to a new location:, then it goes beyond the 302 to a 200, and it all works. When it doesn't work (JHF89) I'm getting a 500 internal server error, then that's it, nothing comes up.   Is the internal error on checkpoint I assume not the in house IDP server.  I can repeat the process over and over to JHF84 and back if anyone from R&D want to look at it.

Can R81.20 JHF89 manage an R82 gateway?    Maybe, I'll try R82.  But it doesn't look like it. https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_RN/Content/Topics-RN/Support...

[the_rock]

Definitely cant manage R82 gateway. You can try, but then you need R82 gw as well.

Andy

[PhoneBoy]

That's only possible across minor versions with a specific JHF level.
R82 is considered a major version.

[JozkoMrkvicka]

Can we expect in near future JHF for R81.10 and R81.20 that will support managing R82 gateways ?

[PhoneBoy]

No, I would not expect this as R81.x and R82 are different major releases.

[Sören · Accepted solution]

@Daniel_Kavan Please check, if your metadata file from the IdP contains the option: "WantAuthnRequestsSigned="true". If yes, please change it to false and upload the metafile again. 

SmartConsole:

[Daniel_Kavan]

Thanks Soren, that did it.  I also updated to JHF90.

[the_rock]

Great tip, thanks @Sören 

Andy

[skandshus]

If i dont have the "wantauth" part in my XML file but seeing the same issue? what do i do then? and what has actually changed in the code since this start's to happen?

[skandshus]

Im seeing this error too.

Did you finally resolve it ?