jdavalos

This plugin should work well if the WP installation is “standalone”. That simply means that when you install WP, are you installing the “standalone” version or the “multisite” version? The former allows you to manage each WP separately, with an admin console for each of them. The latter allows you to manage all WP sites under one common admin console. There are benefits and drawbacks to each.

What type of errors are listed in the log files for the plugin (which is the SP) and the IdP? You should get a single connection to one site to work, first.

In my experience, this plugin works great with some small modifications and use within a standalone WP site. For me, I have not been able to get it to work properly in a multisite installation of WP.

The nice thing about this plugin is that the General tab gives you Status information on the “readiness” of the plugin. Are all of the status checks green? If not, what is red and what is green?

Thanks for confirming.

Are you familiar with the basics of SAML-based authentication and the concepts of an Identity Provider (IdP) and Service Provider (SP)?

What the “SAML 2.0 Single Sign-on” plugin does is act as an SP in a SAML exchange. The SPs job is to process attempts to reach a protected (meaning: requires authentication) resource, but it can only do so for sites that the SP manages. The significance of this to you is that the “SAML 2.0 Single Sign-on” plugin cannot manage access to these two sites as it configured to respond to access attempts to a specific URL, not to multiple URLs.

SiteA – uses some URL, let’s call it https://sitea.truck.com
SiteB – uses some other URL, let’s call it https://siteb.car.com

You may be able to get the plugin to manage multiple URLs by using a multi-site installation of WordPress, but I have not been successful in doing this (you can read about some of my issues in the support logs for the plugin).

Even if you accomplished this, I feel it is somewhat missing the point of the SAML exchange. It is typically the IdP that caches the SAML authentication “cookie” so that the user is not prompted for credentials again when visiting a second site.

The simplest way to accomplish what you want is to configure the IdP with a SAML connection to both SiteA and SiteB. Configure each site (assuming SiteA and SiteB are both WordPress sites) with the “SAML 2.0 Single Sign-on” plugin. It should then be possible for the user’s browser to cache the IdP session “cookie” and prevent the user from having to login to the second site.

@procore

Hello. Is this the scenario you are facing?

SiteA – uses some URL, let’s call it https://sitea.truck.com
SiteB – uses some other URL, let’s call it https://siteb.car.com

Authentication rules should be such that if a user has permission to login to SiteA, they should have permission to login to SiteB and vice-versa.
Further, once a user logs in to SiteA, they should not be prompted to login to SiteB, and vice-versa.

Can you confirm you configured the “Identity Provider” tab, as follows?

IdP name –> This can be any name you like. I prefer to label as “production” or “development”

URL Identifier –> This must be the “entity id” that the IdP has been configured to use. You would need to get this from the IdP

Single Sign-on URL –> This must be the URL at which the IdP is expecting to receive authN requests. You would need to get this from the IdP

Single Logout URL –> This can typically be any URL you want, unless you are actually using this to terminate the IdP session

Certificate Fingerprint –> This must the be the fingerprint of the IdP’s assertion signing certificate. You would need to get this from the IdP

The IdP metadata is stored in this config file, from what I have seen and read.

/wp-content/uploads/saml-20-single-sign-on/etc/config/saml20-idp-remote.ini.

May be worth looking into.

Also, check to see if you have any “redirecting” type plugins installed that may be causing the request of the use_sso=false URL to be directed elsewhere.

Sounds like there is a restriction in place at the IdP that is causing this. or possibly the SP entity was typed incorrectly at the IdP. I think that would generate a different error, though…

Inside the SAML response from the IdP should be a section like this:

<saml:AudienceRestriction>
        <saml:Audience>https://yoursitename.yourdomainname.com/wp-content/plugins/saml-20-single-sign-on/saml/www/module.php/saml/sp/metadata.php/1</saml:Audience>
      </saml:AudienceRestriction>

Make sure that is the name of the SP’s “entity id” as listed on the “General” tab of the plugin settings.

The SSO flow for this plugin should generally work like this:

(1) User requests /wp-admin (Note that only /wp-admin is protected by this plugin. If you want to protect the entire site, look at a plugin that others in the support threads for this plugin has tried, such as “Restricted Site Access”)
(2) The plugin directs the user to the IdP (it is at this point that the user should be prompted to enter credentials)
(3) If the credentials are validated, an assertion will be created and the browser will post the assertion to the SP
(4) If assertion is formatted correctly and contains all of the defined metadata, the user will be shown the requested page

Can you confirm the following?
(A) You have configured the IdP so that it can work with this plugin (the plugin is referred to as the “SP”)? This means you will have needed to create a connection on the IdP that references the “Entity ID” of the SP from the “General” tab.
(B) 403 errors typically mean a URL was requested that was forbidden (meaning, access denied). There could be some restriction in place on the web server to prevent access to that directory/file. More info here:
https://en.wikipedia.org/wiki/HTTP_403
(C) On a final note, just before you see the 403, do you see the browser’s address bar bounce through a few redirections? This would indicate the redirection processes of the SSO process were taking place. You should be receiving a prompt for credentials from the IdP, as well.

1. You can enter this URL on the “Identity Provider” tab. Enter a URL that you want users to see after they logout. It can be any URL you want: a simple page that says “You are signed out.” or a redirect to an intranet page or any other page that holds significance. Enter the URL in https:// or https:// format.

2. On the “Service Provider” tab, you can check the box that says something like “generate a new key for me automatically”, then click “Update”. This will generate a self-signed certificate that would be used in SP SSO or where the IdP requires signed AuthN requests.

This should get rid of the two warnings on the “General” tab.

I have found in my testing that the plugin treats the value in the “groups” attribute as a single value.

This means a few things:
(1) User can be a member of only one group
(2) IdP needs to send the highest-level permission group the user is a member of
(3) You may need to address the fact that by default, the user’s group membership is updated at each login. Somewhere else in the support thread, someone found a way to comment out the functions that update the user’s group membership at each login. The significance of this is that you can manually elevate the role to a higher or lower permission outside of the login process.

I believe the path various based on whether it is a standalone or multisite WP install.

Standalone is /wp-content/uploads/saml-20-single-sign-on/etc/certs/1
Multisite is found in /wp-content/uploads/saml-20-single-sign-on/sites/1/<something>… if I recall, correctly.

Does the plugin pass all checks (the checks are listed in red or green on the “General” tab)?

I have not seen this specific error in my testing, but you can open the simple.php file and look through the comments the author(s) left to get a better understanding of what processes are in play and what the cause may be.

I have only been able to leverage the access and error logs that comes from the web server. This plugin does not seem to log any information within its own directory structure.

Are you using a multisite installation of WP, by chance? Typically, standalone sites gets recognized as site “1” by the SAML 2.0 Single Sign-on plugin, but the authentication source in your case indicates “1/” instead of “/1” as would be appending to the end of some of the SSO-related URLs, as seen on the “General” tab of the plugin’s settings.

Did you manually change that URL, somehow?