SuiteCRM SAML configuration

We are trying to have the SAML configured to our SuiteCRM application. The support team requested us with the below URLs for the Azure configuration.

Login URL: https://.com/index.php?action=Login&module=Users
Reply URL: https://
.com/index.php?module=Home&action=index

After setting up in Azure, Login URL, SLO URL and X509 certificate was setup in the SuiteCRM application.

When we are trying to login the page just goes blank, If anyone here can help us understand where we are going wrong or any detailed document would be helpful.

SuiteCRM Version: 7.10.7

Blank pages are usually accompanied by PHP FATAL errors on one of your logs.

I would also recommend an upgrade to the latest 7.10.x, there are many bugs fixed since your version.

We tried to setup in our test environment which is on version 7.10.11. Its connecting to the Microsoft Signon page, once the Sign in is done the below error is showing.

AADSTS700016: Application with identifier ‘https:///suitecrm/index.php?action=Login&module=Users’ was not found in the directory '34ddb339-7fd0-4f00-*********’. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.

I do not see any errors on the suitecrm.log. I will post here if I see any errors in php_error.log.

Please let us know if I need to verify something. Do you see any issue with the Login and Reply URL which was posted above.

This looks like something peculiar to your web server / security configurations… I am afraid I never saw a problem like this, I am a bit lost on how to help you… :unsure:

I’ve spent a while now trying to get this to work and encountered the same error message. For us, it was a result of a small difference between Azure’s Entity ID and the identifier sent by SuiteCRM (https://crm.example.com:443/… in config.php vs. https://crm.example.com/… in Azure AD). Since SuiteCRM seems to create and send identifier based on the configured site_url and Azure AD is sensitive with the input, I got rid of this error by omiting port from site_url in SuiteCRM’s config.php.

I’m still stuck on an eternal login loop though, so I assume some data on Azure’s end is still incomplete.

We have made the ACS URL and entity ID the same in Azure configurations and it started working there are no other changes done.

ACS URL: https:///suitecrm/index.php?action=Login&module=Users
Entity ID: https://
/suitecrm/index.php?action=Login&module=Users

1 Like

hi hakkih1,
could you please describe how you set up azure/ad/suitecrm?

I’m trying to get it work for a while now and I’m stuck. We’re getting the microsoft login-page, but are redirected to the regular login or get trapped in a never ending loading screen.

your help would be much appreciated!

Hello,

I am hitting the same issue with the latest version that has a Docker image - 7.11.8. I am running SuiteCRM in Kubernetes using the Helm chart and Docker images from Bitnami. SuiteCRM runs fine until I enable SAML and put login/logout URLs and Certificate generate from a Keycloak SAML client.

When I re-open SuiteCRM I get a blank page(see the screenshot attached). In the suitecrm.log file I get these errors showing every few seconds when SAML is enabled :

Wed Sep 11 07:17:32 2019 [149][-none-][FATAL] Exception handling in /bitnami/suitecrm/include/MVC/Controller/SugarController.php:400
Wed Sep 11 07:17:32 2019 [149][-none-][FATAL] Exception in Controller: Invalid array settings: sp_acs_url_invalid, sp_sls_url_invalid
Wed Sep 11 07:17:32 2019 [149][-none-][FATAL] backtrace:
#0 /bitnami/suitecrm/vendor/onelogin/php-saml/src/Saml2/Auth.php(177): OneLogin\Saml2\Settings->__construct(Array)
#1 /bitnami/suitecrm/modules/Users/authentication/SAML2Authenticate/SAML2Authenticate.php(74): OneLogin\Saml2\Auth->__construct(Array)
#2 /bitnami/suitecrm/modules/Users/Login.php(46): SAML2Authenticate->pre_login()
#3 /bitnami/suitecrm/include/MVC/View/SugarView.php(834): include_once('/bitnami/suitec...')
#4 /bitnami/suitecrm/include/MVC/View/views/view.classic.php(72): SugarView->includeClassicFile('modules/Users/L...')
#5 /bitnami/suitecrm/include/MVC/View/SugarView.php(226): ViewClassic->display()
#6 /bitnami/suitecrm/include/MVC/Controller/SugarController.php(435): SugarView->process()
#7 /bitnami/suitecrm/include/MVC/Controller/SugarController.php(375): SugarController->processView()
#8 /bitnami/suitecrm/include/MVC/SugarApplication.php(113): SugarController->execute()
#9 /bitnami/suitecrm/index.php(52): SugarApplication->execute()
#10 {main}

Nothing shows in Keycloak logs, so I don’t think it reaches it at all.

from what I understand the SAML2Authentication code in SuiteCRM depends on a non-working version of onelogin or it is just broken

I have updated onelogin and made some changes in my companies instance and SAML works for us via G-Suite

please find attached a zip file with the aforementioned changes.

replace the SAML2Authenticate folder which can be found at
<suitecrm_dir>/modules/Users/authentication/SAML2Authenticate

known to work on SuiteCRM versions
7.10.*
7.11.*

@madmart could you please provide those changes on Github? Or at least an Issue, explaining what is necessary.

Thanks

@pgr it was sometime last year when I worked on it so I don’t remember the exact nature of the issue but
we recently upgraded our instance to 7.11.5 which reverted my changes and caused SSO to keep looping back to the login prompt for google so I assume there is a problem still.

I’ll have a look at my code and the differences to a fresh install and write something up

1 Like

We got SAML authentication using Azure AD working some time after my last post. I can’t remember what exactly was the problem and how did I get it working (I think in the end it was some stupid mistake on my part). It did require a fair bit of trial-and-error, but I didn’t need to change any line of the code.

Just finished reviewing the two folders. and it turns out that onelogin has been updated since last year to the same version I am using
not sure what happened during the upgrade the other day but at this point the folder I sent in isn’t necessary

Maybe what happened was this

https://github.com/salesagility/SuiteCRM/pull/7574

or that you ran a “composer install --no-dev” and it updated the software for you…

anyway I’m glad it’s up to date now.

Hello Guys,

I am still not sure what to do on this. I get exactly the same issue. I tried running - “composer install --no-dev” but it makes no difference.
Is there a newer version of SuiteCRM where this is fixed, I am still trying with - 7.11.8 ?

Hi Guys,

Exactly the same issue as Boris - Error 403 app_not_configured_for_user

7.11.8

I’m able to get to the accounts.google.com… login screen, but after logging, It does not redirect back to suitecrm.

When bypassing the saml, logging in is fine, then logging out also work properly and sends me to the SLO.

So the disconnect is an authentication mishap happening between accounts.google.com… and suitecrm .

There is an update that is quite critical to apply if you’re running 7.11.8:

https://github.com/salesagility/SuiteCRM/pull/7762/files

And then run a Admin / Repairs / Rebuild .htaccess

Tell me if that fixes anything.

1 Like

Thanks for getting back to me so quickly.

I ended up replacing the entire /modules/Users/authentication/SAML2Authenticate directory with the most recent version (updated 2 months ago as of this post I believe) last night, as well as re-updating config_override.php with the x509 cert hash. And it worked!

I have also updated the UpgradeAccess.php as per your suggestion (looks much cleaner).

Thanks for your help

Hi,

I upgraded to 7.11.10 and SAML is broken again. Can’t figure out what’s going on.

This is what my server log is saying:

[error] 4231#4231: 211 FastCGI sent in stderr: “PHP message: PHP Warning: session_destroy(): Trying to destroy uninitialized session in …/include/MVC/SugarApplication.php on line 172” while reading response header from upstream, client: ***.**.***.***, server: ***.***.***.***, request: “GET / HTTP/2.0”, upstream: “fastcgi://unix:/run/php/php7.2-fpm.sock:”,

Thank You

That is strange :huh:

Can you try the htaccess repair again? But I don’t see why that should be necessary, I am just trying to find some workaround…