idgold

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.
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.
<h4>What it does</h4>
<ul>
<li>SAML 2.0 SP with HTTP-Redirect and HTTP-POST bindings, signed AuthnRequests, signed/encrypted assertion handling, SP-initiated and IdP-initiated Single Logout.</li>
<li>Multi-IdP — configure multiple identity providers, let users choose via a button or URL parameter (<code>?idp=slug</code>).</li>
<li>Attribute mapping — map SAML attributes to WordPress user fields (first name, last name, email, display name, plus arbitrary user_meta).</li>
<li>Role mapping — 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>Page access control — 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>WooCommerce integration (optional) — map SAML attributes to WooCommerce customer fields; auto-link SSO users to existing customers.</li>
<li>Audit log with configurable retention.</li>
<li>Force-SSO mode with emergency bypass via <code>OASSO_BYPASS</code> constant in <code>wp-config.php</code>.</li>
</ul>
<h4>Privacy</h4>
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.
<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>
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.
<h4>Identity Provider metadata fetch</h4>
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.
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.
<h4>SAML single sign-on flow</h4>
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.
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.).

Open Access SSO

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

secureparrot

SecurePie SSO SAML is a SAML 2.0 Single Sign-On (SSO) plugin for WordPress that provides enterprise SSO login, SAML login, and federated login via any SAML 2.0 Identity Provider — including Azure AD (Entra ID), Okta, Google Workspace, OneLogin, ADFS, Auth0, PingFederate, and Keycloak.
Whether you need SAML SSO for an intranet, an enterprise SSO portal for customers, or federated authentication for your team, this plugin turns your WordPress site into a SAML Service Provider with zero external dependencies.
SecurePie SSO SAML allows you to configure your WordPress site as a SAML 2.0 Service Provider (SP), enabling Single Sign-On with any SAML 2.0 compliant Identity Provider (IdP) such as Azure AD, Okta, Google Workspace, OneLogin, ADFS, and more.
This is a zero-dependency plugin — it uses only PHP’s built-in <code>dom</code>, <code>openssl</code>, and <code>zlib</code> extensions. No Composer, no external libraries, no conflicts with other plugins.
<h4>Features</h4>
<ul>
<li>Full SAML 2.0 SSO — AuthnRequest generation, Response validation, user provisioning</li>
<li>SP Metadata Endpoint — Auto-generated metadata XML for easy IdP configuration</li>
<li>IdP Metadata Parsing — Import IdP settings from a metadata URL or XML file</li>
<li>XML Digital Signature Verification — RSA-SHA256 and RSA-SHA1 support</li>
<li>Security Hardened — XXE prevention, signature wrapping attack protection, replay prevention, audience validation</li>
<li>Attribute Mapping — Map SAML attributes to WordPress user fields (username, email, first name, last name, display name)</li>
<li>Role Mapping — Assign WordPress roles based on IdP group/role attributes</li>
<li>Auto User Provisioning — Automatically create WordPress users on first SSO login</li>
<li>SSO Login Button — Customizable SSO button on the WordPress login page</li>
<li>Force SAML Login — Optionally redirect all login attempts through the IdP</li>
<li>Single Logout (SLO) — Send LogoutRequest to the IdP when users log out of WordPress</li>
<li>Test Configuration — Validate your SSO setup and see returned attributes before going live</li>
<li>HTTP-Redirect and HTTP-POST Bindings — Support for both SAML binding types</li>
<li>Clean Admin Interface — Professional tabbed settings page with copy-to-clipboard functionality</li>
</ul>
<h4>Use Cases</h4>
<ul>
<li>Enterprise SSO — Centralize WordPress login through your corporate Identity Provider so employees use one set of credentials.</li>
<li>SAML Login for Customer Portals — Let B2B customers sign in to your WordPress site using their own SAML SSO identity.</li>
<li>Federated Login Across Sites — Use a single SAML IdP to federate authentication across multiple WordPress installs.</li>
<li>SSO Authentication for Membership Sites — Replace WordPress’s default signin flow with SAML SSO login from Azure AD, Okta, or Google Workspace.</li>
<li>Intranet Single Sign-On — Add WordPress to your existing SSO ecosystem alongside other SAML 2.0 enabled apps.</li>
</ul>
<h4>Supported Identity Providers</h4>
<ul>
<li>Microsoft Azure Active Directory (Entra ID)</li>
<li>Okta</li>
<li>Google Workspace</li>
<li>OneLogin</li>
<li>Salesforce</li>
<li>Auth0</li>
<li>PingFederate</li>
<li>Shibboleth</li>
<li>ADFS (Active Directory Federation Services)</li>
<li>Keycloak</li>
<li>Any SAML 2.0 compliant IdP</li>
</ul>
<h4>Setting up SAML SSO with Azure AD (Entra ID)</h4>
Connecting WordPress to Azure AD / Entra ID for SAML SSO with SecurePie takes about ten minutes:
<ol>
<li>In the WordPress admin, open SecurePie SSO → Service Provider and copy the SP Entity ID and ACS URL.</li>
<li>In Azure, create a new Enterprise Application of type “Non-gallery application” and open its Single sign-on → SAML blade.</li>
<li>Paste the SP Entity ID into Azure’s Identifier (Entity ID) field and the ACS URL into the Reply URL (Assertion Consumer Service URL) field.</li>
<li>Under “SAML Signing Certificate”, download the Federation Metadata XML (or copy the Login URL and certificate).</li>
<li>Back in WordPress, open Identity Provider → Quick Setup and either upload the metadata XML or paste the metadata URL. SecurePie auto-fills Entity ID, Login URL and X.509 Certificate.</li>
<li>Assign your Azure users / groups to the Enterprise Application, then run Test Configuration in WordPress to confirm attributes flow through correctly before enabling the SSO button on the login page.</li>
</ol>
<h4>Setting up SAML SSO with Okta</h4>
Okta-to-WordPress SAML SSO with SecurePie follows the same pattern:
<ol>
<li>In the WordPress admin, open SecurePie SSO → Service Provider and copy the SP Entity ID, ACS URL and Single Logout URL.</li>
<li>In the Okta admin, go to Applications → Create App Integration → SAML 2.0, give the app a name, and continue to step 2 of Okta’s wizard.</li>
<li>Paste the SP Entity ID into Okta’s Audience URI (SP Entity ID) field and the ACS URL into the Single Sign-on URL field.</li>
<li>Configure Okta’s attribute statements to send <code>email</code>, <code>firstName</code>, <code>lastName</code>, and optionally a <code>groups</code> claim for role mapping.</li>
<li>After saving, open the Okta Sign On tab, click View SAML setup instructions, and copy the Identity Provider Single Sign-On URL, Identity Provider Issuer and the X.509 Certificate.</li>
<li>Back in WordPress, paste these into Identity Provider Setup (or use Okta’s metadata URL). Run Test Configuration to verify the SAML assertion before going live.</li>
</ol>
<h4>Requirements</h4>
<ul>
<li>PHP 7.4 or higher</li>
<li>PHP extensions: <code>dom</code>, <code>openssl</code>, <code>zlib</code> (enabled by default on most hosts)</li>
<li>WordPress 5.8 or higher</li>
</ul>
<h3>External Services</h3>
This plugin implements the SAML 2.0 protocol, which requires communication with an external Identity Provider (IdP) that is configured by the site administrator. No data is sent to any external service without the administrator explicitly configuring the connection.
<h4>Identity Provider Communication</h4>
When a user initiates SSO login, the plugin redirects the user’s browser to the Identity Provider’s SAML Login URL (configured by the administrator). The following data is sent as part of the standard SAML 2.0 AuthnRequest:
<ul>
<li>The Service Provider Entity ID (your site’s identifier)</li>
<li>The Assertion Consumer Service URL (your site’s callback URL)</li>
<li>A unique request ID for replay prevention</li>
</ul>
The Identity Provider then authenticates the user and sends a SAML Response back to your site containing the user’s identity attributes (such as email, name, and group membership).
This communication is entirely between your WordPress site and the IdP that you configure. No data is sent to SecurePie or any other third party.
The terms of service and privacy policy for the Identity Provider depend on which provider you choose to configure (e.g., Microsoft Azure AD, Okta, Google Workspace). Please consult your Identity Provider’s documentation for their specific terms.
<h4>IdP Metadata Import (Optional)</h4>
The plugin can optionally fetch Identity Provider metadata from a URL provided by the administrator. This is a one-time server-to-server request to retrieve the IdP’s public configuration (Entity ID, Login URL, X.509 Certificate). No user data is sent during this request.
<h4>SAML Attribute Namespace URIs</h4>
The plugin references standard SAML attribute namespace URIs (e.g., <code>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress</code>) as identifiers within SAML assertions. These are XML namespace strings used for attribute identification and are not HTTP requests to external services.

SecurePie SSO SAML — Single Sign-On, SAML Login & Enterprise SSO for WordPress

SAML 2.0 SSO for WordPress. Enterprise login with Azure AD, Okta, Google Workspace, OneLogin, ADFS & any SAML 2.0 Identity Provider.

Open Access SSO vs SecurePie SSO SAML — Single Sign-On, SAML Login & Enterprise SSO for WordPress