SuiteCRM 8 SAML Azure Hslavich

I am using hslavich onelogin bundle with SuiteCRM 8.5.1 and have configured SAML to the extent that I get to login with my IdP (Azure) when i access “https:///”. However after the successful login I get redirected to "“https:///” which results in a 404 Not found.

It doesnt matter what I state as the ACS url. I have tried “https:///” and “https:///” which for both I have seen in examples on the web.

But it seems like no endpoint will redirect me to an authenticated session in SuiteCRM. I only get to “Page not found”. Feels like I have looked in every file/setting but cannot figure out what endpoint to configure.

Also trying to reach “https:///” gives a redirect to “https:///” (which I have not stated anywhere as far as I know).

Please advise if you feel you might have an answer.

It may be worth focusing on the reason for the 404 error on saml/login.
This should return 401 Unauthorised when correctly configured and accessed via a standard web browser directly.

Are you using Apache and are rewrites enabled correctly?
Any errors in your logs?
Cache’s cleared etc?

Hi and thanks for the reply.

Yes using apache. My RewriteBase in .htaccess (/public/legacy) is pointing to - otherwise untouched.

apache auth.log only shows the 404 for the endpoint /saml/login
Other logs not really populated since I don’t get access to the app I guess…

Cache is cleared - yes

RewriteBase in /public/legacy/.htaccess should usually be /legacy/

If you need to have some other value to make it work correctly, this may point to a configuration issue elsewhere.

Changed it to /legacy/ only for RewriteBase but still get 404 after successful Azure login on
[404 Not Found (]

Any other ideas? :slight_smile:

What prompted you to change .htaccess in the first place?

i.e. what issue were you trying to resolve and has it returned since that change?

What does your apache virtual host config look like?

I have been trying different things to resolve the issue and made some changes to the RewriteBase. Nothing ever resolved the issue and RewriteBase is now changed back to /legacy/ as you stated. Issue persists.

This is my suitecrm.conf in /etc/apache2/sites-available:

<VirtualHost *:80>
#   ServerAdmin
  Redirect permanent /
#   DocumentRoot /var/www/html/suitecrm/public
#   <Directory /var/www/html/suitecrm/public>
#       AllowOverride All
#       Order Allow,Deny
#       Allow from All
#   </Directory>
#   ErrorLog ${APACHE_LOG_DIR}/suitecrm_error.log
#   CustomLog ${APACHE_LOG_DIR}/suitecrm_access.log combined

<IfModule mod_ssl.c>
<VirtualHost *:443>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/suitecrm/public

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf

        SSLCertificateFile /var/local/letsencrypt/fullchain.pem
        SSLCertificateKeyFile /var/local/letsencrypt/key.pem
        Include /etc/apache2/ssl/common.conf

Your directory directive is commented out.
Please try moving it to the 443 section and removing the comments so that AllowOverride is active.

See here for more information:

Thanks for pointing that out! That section is now active and after logging in to Azure I get a loop where Azure is refreshing the SAML request indefinitely. Not passing me through to an authenticated SuiteCRM-session :frowning:

Can you confirm that the following entries are correct? This is what I have now - but it does not feel right…


(hslavich_onelogin_saml.yaml sp)


It’s not clear from your response if the 404 error is now gone, but it sounds like it is. If so then moving on to the SAML config is the next step. If not it’s worth continuing your investigation into that issue.

Your ID’s don’t look correct, perhaps you are mixing up the setup documentation for SuiteCRM 7 and SuiteCRM 8. Here is a link to the documentation showing what should be in each section:

Some examples on the Azure side:

And on the Suite config side:

below is my current config and it still gives me a 404 Not Found for the endpoint

Where it now redirects me after successful login to Azure.

Azure side:

Identifier (Entity ID)

Reply URL (Assertion Consumer Service URL)

SuiteCRM side:

  # Basic settings
    entityId: ''
      url: ''
      binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
      url: ''
      binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
    x509cert: 'AbCDefGHiJkLmNoPqRSTUvXyZdalskdfjaslkfjaslkdjaslkdjalksjdlkasjdlkasjdlkasjdlkasjd>
    entityId: ''
      url: ''
      binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST'
      url: ''
      binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
 #   privateKey: '/var/www/html/docroot/certs/key.pem'
  # Optional settings
  baseurl: ''

So 404 is still there…

In that case it would be worth focusing on why you are getting a 404 response when you should receive a 401.

This is unlikely to be related to your SuiteCRM code or saml config and more likely to be your server setup or configuration.

You can see from the demo, the saml/acs url returns 401

Servers are notoriously challenging to diagnose remotely as the config and setup can vary significantly between OS types, versions etc.

It’s usually worth reviewing the installation documents to ensure you meet all of the requirements, especially around the PHP and Apache modules and configuration.

Thanks for pushing me in the right direction! I digged around and realized that a2enmod rewrite was not enabled :roll_eyes:. Enabling this got me passed by the 404.

Now, I face a redirect to (blank page) after a succesful Azure login.

Inspection tools (network) give me:
saml2 - i get the request from MS
saml/acs -302 - 200 - 403 Invalid CSRF token
(LEGACYSESSID=deleted; expires=Thu, 01-Jan-1970)

I also see an ERROR in prod.log

request.ERROR: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: “Invalid CSRF token” at /var/www/html/suitecrm/core/backend/Security/CSRFValidationListener.php line 95

I tried to comment out line 95 for testing but it only renders the logout page correctly with the correct logos and so forth.

Any of this makes sense to you? I am very grateful for you helping me out!

Re-direct to /logged-out was due to:

security.INFO: Authenticator failed. {“exception”:“[object] (Symfony\Component\Security\Core\Exception\AuthenticationException(code: 0): Attribute "email" not found in SAML data at /var/www/html/suitecrm/core/backend/Security/Saml/AppSamlAuthenticator.php:41)”,“authenticator”:“App\Security\Saml\AppSamlAuthenticator”}

Ended up changing .env.local to:

Now working as expected.


It’s great to hear you solved the problem and thanks for posting the solution. Someone else may find it useful in the future.

1 Like