idgold

<p>Open Access SSO is a SAML 2.0 Service Provider for WordPress. It lets users sign in to your site through any standard SAML identity provider (Microsoft Entra ID, Okta, OneLogin, Keycloak, ADFS, Shibboleth, NetIQ Access Manager, etc.) instead of (or alongside) the built-in WordPress login form.</p>
<p>Built from scratch as a clean-room implementation. Fully open-source under GPLv2+. No paid tier, no telemetry. Its only third-party libraries are xmlseclibs (MIT) for XML signature handling and phpseclib (MIT) for RSA-OAEP key unwrapping — both bundled, and neither makes any network call.</p>
<h4>What it does</h4>
<ul>
<li><strong>SAML 2.0 SP</strong> with HTTP-Redirect and HTTP-POST bindings, signed AuthnRequests, signed/encrypted assertion handling, SP-initiated and IdP-initiated Single Logout.</li>
<li><strong>Multi-IdP</strong> — configure multiple identity providers, let users choose via a button or URL parameter (<code>?idp=slug</code>).</li>
<li><strong>Attribute mapping</strong> — map SAML attributes to WordPress user fields (first name, last name, email, display name, plus arbitrary user_meta).</li>
<li><strong>Role mapping</strong> — assign WordPress roles based on SAML attribute values, with exact / contains / regex match types, per-IdP rule sets, deny-unmapped option, default-role fallback.</li>
<li><strong>Page access control</strong> — restrict pages, posts, and custom post types to specific roles or to “logged in via SSO” users; per-page meta box; <code>[oasso_restrict]</code> shortcode.</li>
<li><strong>WooCommerce integration</strong> (optional) — map SAML attributes to WooCommerce customer fields; auto-link SSO users to existing customers.</li>
<li><strong>Audit log</strong> with configurable retention.</li>
<li><strong>Force-SSO mode</strong> with emergency bypass via <code>OASSO_BYPASS</code> constant in <code>wp-config.php</code>.</li>
</ul>
<h4>Privacy</h4>
<p>This plugin’s only outbound HTTP requests go to the IdP metadata URL you enter: once when an administrator clicks “Fetch IdP Metadata from URL”, and — only if you turn on the optional certificate-rotation check for an IdP — on a recurring WP-Cron schedule that re-fetches that same URL. Certificate-rotation checks are disabled by default. No telemetry, no analytics, no calls to any third-party service. All configuration is stored in <code>wp_options</code> on your own site.</p>
<h4>Requirements</h4>
<ul>
<li>WordPress 6.0+</li>
<li>PHP 8.1+</li>
<li>A SAML 2.0 identity provider you control or have access to.</li>
</ul>
<h3>External Services</h3>
<p>This plugin is a SAML 2.0 Service Provider (SP). It sends no telemetry or analytics and never connects to any service operated by the plugin author. Its only external interactions are with the SAML Identity Provider (IdP) that you, the site administrator, configure — for example Microsoft Entra ID, Okta, OneLogin, Keycloak, ADFS, Shibboleth, or NetIQ Access Manager. There is no built-in or default IdP; the IdP is chosen and operated by you or your organisation.</p>
<h4>Identity Provider metadata fetch</h4>
<p>When an administrator clicks “Fetch IdP Metadata from URL” in the plugin’s admin screens, the plugin makes a single server-side HTTP GET request to the metadata URL the administrator entered. No site or user data is sent beyond a standard HTTP request; the response (SAML metadata XML) is parsed and stored in your site’s database. This never happens on the front end.</p>
<p>Optionally, you can enable a certificate-rotation check for an IdP (off by default). When enabled, WP-Cron re-fetches that same administrator-entered metadata URL on a schedule (for example daily) so the plugin can warn you before the IdP’s signing certificate expires or changes. This is the only automatic outbound request the plugin makes, it is opt-in per IdP, and it contacts only the metadata URL you configured.</p>
<h4>SAML single sign-on flow</h4>
<p>When a visitor signs in through SSO, their browser is redirected to your configured IdP (carrying a standard SAML AuthnRequest). After the visitor authenticates, the IdP returns a signed SAML assertion to your site, which the plugin validates and uses to create or update the corresponding WordPress user. The data exchanged is the SAML authentication request and response — which includes the user identifier and whatever attributes your IdP is configured to release. This exchange happens only when a visitor initiates an SSO login.</p>
<p>Because the IdP is a service you select and operate (or that your organisation operates), its terms of service and privacy policy are defined by that provider. Consult your chosen identity provider’s own documentation for those terms (for example, the privacy and terms pages of Microsoft Entra ID, Okta, OneLogin, etc.).</p>


Open Access SSO

Open-source SAML 2.0 SSO and access control. Map identity-provider attributes to WordPress roles. Multi-IdP, GPL-licensed.

Daniel Bachhuber

Chris Reynolds

John Spellman

Pantheon Systems

Josh Koenig

Anais Pantheor

<p>SAML authentication for WordPress, using the bundled OneLogin SAML library or optionally installed <a href="https://simplesamlphp.org/" rel="nofollow ugc">SimpleSAMLphp</a>. OneLogin provides a SAML authentication bridge; SimpleSAMLphp provides SAML plus a variety of other authentication mechanisms. This plugin acts as a bridge between WordPress and the authentication library.</p>
<p>If your organization uses Google Apps, <a href="https://pantheon.io/docs/wordpress-google-sso/" rel="nofollow ugc">integrating Google Apps with WP SAML Auth</a> takes just a few steps.</p>
<p>The standard user flow looks like this:</p>
<ul>
<li>User can log in via SAML using a button added to the standard WordPress login view.</li>
<li>When the button is clicked, the user is handed off to the authentication library. With OneLogin, the user is redirected to the SAML identity provider. With SimpleSAMLphp, the user is redirected to the SimpleSAMLphp install.</li>
<li>Once the user is authenticated with the identity provider, they’re redirected back to WordPress and signed in to their account. A new WordPress user will be created if none exists (although this behavior can be disabled).</li>
<li>When the user logs out of WordPress, they are also logged out of the identity provider.</li>
</ul>
<p>A set of configuration options allow you to change the plugin’s default behavior. For instance, <code>permit_wp_login=>false</code> will force all authentication to go through the SAML identity provider, bypassing <code>wp-login.php</code>. Similiarly, <code>auto_provision=>false</code> will disable automatic creation of new WordPress users.</p>
<p>See installation instructions for full configuration details.</p>
<h3>Installing SimpleSAMLphp</h3>
<p>The plugin supports both SimpleSAMLphp v1.x and v2.x. The autoloader is automatically detected:</p>
<p><strong>SimpleSAMLphp v2.x</strong> uses <code>vendor/autoload.php</code><br />
<strong>SimpleSAMLphp v1.x</strong> uses <code>lib/_autoload.php</code></p>
<h4>Default Search Paths</h4>
<p>The plugin automatically searches for SimpleSAMLphp in these locations:<br />
* <code>ABSPATH . 'simplesaml'</code><br />
* <code>ABSPATH . 'private/simplesamlphp'</code><br />
* <code>ABSPATH . 'simplesamlphp'</code><br />
* <code>ABSPATH . 'vendor/simplesamlphp/simplesamlphp'</code> (Composer installation)<br />
* <code>plugin_dir_path . 'simplesamlphp'</code></p>
<p>For each path, the plugin checks for both <code>vendor/autoload.php</code> (v2.x) and <code>lib/_autoload.php</code> (v1.x).</p>
<p><strong>This means Composer installations work automatically!</strong> If you run <code>composer require simplesamlphp/simplesamlphp</code> in your site root, the plugin will find it without any additional configuration.</p>
<h4>Composer Installation (Advanced)</h4>
<p>If you install SimpleSAMLphp via Composer to a <strong>custom location</strong> (not the standard <code>vendor/simplesamlphp/simplesamlphp</code>), you can specify the autoloader path:</p>
<pre><code>add_filter( 'wp_saml_auth_option', function( $value, $option_name ) {
    if ( 'simplesamlphp_autoload' === $option_name ) {
        // Point to your custom Composer vendor autoloader
        return '/custom/path/vendor/autoload.php';
    }
    return $value;
}, 10, 2 );
</code></pre>
<h4>Custom Installation Paths</h4>
<p>If SimpleSAMLphp is installed in a non-default location, you can set custom search paths with the <code>wp_saml_auth_simplesamlphp_path_array</code> filter:</p>
<pre><code>add_filter( 'wp_saml_auth_simplesamlphp_path_array', function( $simplesamlphp_path_array ) {
    // Override default paths with custom paths
    return [ '/custom/path/to/simplesamlphp' ];
} );
</code></pre>
<p>Or define an explicit autoloader path with the <code>wp_saml_auth_ssp_autoloader</code> filter:</p>
<pre><code>add_filter( 'wp_saml_auth_ssp_autoloader', function( $ssp_autoloader ) {
    return ABSPATH . 'path/to/simplesamlphp/vendor/autoload.php';
} );<h3>WP-CLI Commands</h3>
</code></pre>
<p>This plugin implements a variety of <a href="https://wp-cli.org" rel="nofollow ugc">WP-CLI</a> commands. All commands are grouped into the <code>wp saml-auth</code> namespace.</p>
<pre><code>$ wp help saml-auth

NAME

  wp saml-auth

DESCRIPTION

  Configure and manage the WP SAML Auth plugin.

SYNOPSIS

  wp saml-auth <command>

SUBCOMMANDS

  scaffold-config      Scaffold a configuration filter to customize WP SAML Auth usage.
</code></pre>
<p>Use <code>wp help saml-auth <command></code> to learn more about each command.</p>
<p><strong>Note:</strong> The <code>scaffold-config</code> command generates a configuration function with default values. The <code>simplesamlphp_autoload</code> option is not included in the scaffolded output because the plugin auto-detects SimpleSAMLphp installations. Only add this option manually if SimpleSAMLphp is in a non-standard location.</p>
<h3>Contributing</h3>
<p>See <a href="https://github.com/pantheon-systems/wp-saml-auth/blob/main/CONTRIBUTING.md" rel="nofollow ugc">CONTRIBUTING.md</a> for information on contributing.</p>


Open Access SSO vs WP SAML Auth