Ok folks, the answer is "Yes". That is enough to break SAML, and you should not get tripped up by that last error message; it's not about "the username", it's about the parsing of the entire response.
R&D: You could do better with the error messages here, please.
The fix for this was (copy/paste from our Entra ID admin):
"I changed the groups to use SamAccountName instead of displayname since it is an on-prem group. I changed the username claim to not have a namespace."
I also had the Entra admin to edit the claim and return a custom "groups" attribute, and map it to the Entra group that is sync'ed from Active Directory (which was the group's sAMAccountName value). The "username" claim was also edited and set to the UPN ([email protected]).
The username and groups claim now reads:
23/07/26 19:30:27,229 INFO dleserver.saml.Utils [qtp-212426152-101]: attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname : Duane
23/07/26 19:30:27,229 INFO dleserver.saml.Utils [qtp-212426152-101]: attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname : Toler
23/07/26 19:30:27,229 INFO dleserver.saml.Utils [qtp-212426152-101]: attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress : [email protected]
23/07/26 19:30:27,229 INFO dleserver.saml.Utils [qtp-212426152-101]: attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name : [email protected]
23/07/26 19:30:27,229 INFO dleserver.saml.Utils [qtp-212426152-101]: attribute username : [email protected]
23/07/26 19:30:27,229 INFO dleserver.saml.Utils [qtp162443092-1949527]: attribute groups : Check Point SmartConsole Administrators
and the following lines showing success are:
23/07/26 18:57:58,905 INFO dleserver.saml.CpRequestAssertionConsumerService [qtp-212426152-102]: login key 4d71d3ee-****-****-****-************ for state abcdef09-ffff-aaaa-bbbb-0123456789ab
23/07/26 18:57:58,918 INFO dleserver.saml.CPSPStateManager [qtp-212426152-102]: setReadyState. 4d71d3ee-****-****-****-************ org.apache.cxf.rs.security.saml.sso.state.ResponseState@f3457661
the "***" are literal, from the debug log itself, not my obfuscation.
In the management server, I created an "Identity Provider Administrator Group", gave it a name (any name you want), and in the "Group ID/Name" box I gave it the specific name of Entra/AD group ("Check Point SmartConsole Administrators"). I set a permissions profile (just like any admin). Publish.
Open SmartConsole, click the icon beside the username, change it to Identity Provider. For MDS, specify a management domain, click the big green button. Web browser opens, redirects to Entra ID, login with username/password (and MFA). For MFA with passkey, this didn't work to connect to my Microsoft Authenticator app, so I had to choose "try another way" and use the rotating code in my MS Auth app for that user account. Or... install a passkey on the browser of the machine where you run SmartConsole (BEWARE if this is a shared PC!!).
Once authentication passes, the browser is redirected back to SmartConsole, and... ta-da! You're in, and with that permissions profile.
Enjoy!