salesagility / SuiteCRM

SuiteCRM - Open source CRM for the world
https://www.suitecrm.com
GNU Affero General Public License v3.0
4.27k stars 2.03k forks source link

SuiteCRM 8.5.1 - SAML login gets always redirected to logged-out (Invalid CSRF token exception in the logs) #10379

Closed stefanomarty closed 3 months ago

stefanomarty commented 3 months ago

Issue

I am trying to setup a SAML login on a fresh SuiteCRM v.8.5.1 install.

I followed the instructions here: https://docs.suitecrm.com/8.x/admin/configuration/saml-configuration/

IDP is a Keycloak instance already serving other apps without errors. .env.local is configured to use the email as SAML_USERNAME_ATTRIBUTE (user are registered in SuiteCRM with email as username):

###> AUTH_TYPE ###
AUTH_TYPE=saml
###< AUTH_TYPE ###

###> SAML CONFIG ###
SAML_AUTO_CREATE=enabled
SAML_USERNAME_ATTRIBUTE=email
SAML_USE_ATTRIBUTE_FRIENDLY_NAME=true
###< SAML CONFIG ###

The SAML exchange looks good, I can see the SAML 2.0 Assertion and the SAML 2.0 AttributeStatement (using the SAM-tracer extension in Firefox). Here's an example of the answer from Keycloak:

SAML2.0 Response
Destination https://crm.[redacted]/saml/acs
ID  ID_9d50caa5-...
Version 2.0
IssueInstant    2024-03-16T12:44:34.788Z
Issuer  https://sso.[redacted]/realms/DHB
SAML 2.0 Assertion
ID  ID_12107b06-6361-...
Version 2.0
IssueInstant    2024-03-16T12:44:34.788Z
Subject demoagent
SAML 2.0 AttributeStatement
last_name   Demo
name    demoagent
email   demoagent@[redacted]
first_name  Agent
Embedded certificates
Certificate 0   Download

It looks fine to me, all the attributes are the correct ones and they coincidw with the user already registered in the CRM, but the user never get logged in, they always are redirected to logged-out blank page.

In the suitecrm log I can see the problem is caused by "Invalid CSRF token"

[2024-03-16 12:30:04] request.ERROR: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: "Invalid CSRF token" at /opt/suitecrm-8-5-1/core/backend/Security/CSRFValidationListener.php line 95 {"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\AccessDeniedHttpException(code: 0): Invalid CSRF token at /opt/suitecrm-8-5-1/core/backend/Security/CSRFValidationListener.php:95)"} []

I have tried many different suggestions fund on the internet but nothing solved the issue so far.

What am I missing?

Thanks in advance for your help!

stefanomarty commented 3 months ago

Well, it seems there was a configuration error on the IdP and the Invalid CSRF token was just a consequence. After a more careful check of the log I found this error:

[2024-03-16 14:54:02] app.ERROR: Found attributes: Array (     \
[Family name] => Array         (             [0] => Demo         )      \
[Full name] => Array         (             [0] => demoagent         )      \
[Email address] => Array         (             [0] => demoagentboiler@[Redacted]         )      \
[Given name] => Array         (             [0] => Agent         )      \
[sessionIndex] => 70c1c409-432c-4115-a1f8-175ca93918f0::e74c7058-39e9-4238-bc26-51a410f7592a )  [] []

and those array index names looked very strange: [Family name],[Full name],[Email address] instead of [last_name],[username],[email], etc...

I checked on Keycloak and those index names where saved in the "Friendly name" field of the User attribute. After changing the "Friendly name" field to the original SAML attribute name, the issue was solved and the user were able to login. I was misled by the SAML-tracer extension in Firefox because those "Friendly names" never showed up there and everything looked normal.

I still don't understand why the SAML plugin reads those Friendly names instead of the standard SAML Attribute name, but once you know it you can easily solve the problem. Hope this can help someone facing the same problem!

chris001 commented 3 months ago

why the SAML plugin reads those Friendly names instead of the standard SAML Attribute name

Is it possibly because: SAML_USE_ATTRIBUTE_FRIENDLY_NAME=true You can set that to false and it should use the standard SAML Attribute name.

stefanomarty commented 3 months ago

why the SAML plugin reads those Friendly names instead of the standard SAML Attribute name

Is it possibly because: SAML_USE_ATTRIBUTE_FRIENDLY_NAME=true You can set that to false and it should use the standard SAML Attribute name.

Ahahah... it was just under my nose for all these hours and I simply couldn't see it!!!

That's why you always need another pair of eyes, sometimes you can't see what's right in front of you!

Thanks! 👍