Open Access SSO

Let your team sign in to WordPress with the company login they already use — one click, no extra password to manage, reset, or chase down.

Open Access SSO connects your WordPress site to the identity provider your organisation already runs, so people log in through your trusted corporate sign-in instead of juggling yet another WordPress password. It works with any standard SAML 2.0 identity provider — including Microsoft Entra ID (Azure AD), Okta, OneLogin, Keycloak, ADFS, Shibboleth, and NetIQ Access Manager (now OpenText) — and it’s completely free and open-source, with no premium tier, no license key, and no upsell.

Everything below is included. Nothing is locked, metered, or “Pro.”

Why site admins choose it

• Free, forever. Every feature ships in the GPLv2-or-later codebase — full role mapping, multi-IdP, access control, and more, at no cost. No paid plan, no per-site license, no feature gates.
• Privacy-first by design. No telemetry, no analytics, no “phone home,” and no external CDN. Your configuration never leaves your site.
• Works with the identity provider you already have. Point-and-click setup for any standards-compliant SAML 2.0 IdP — no developer required for normal use.
• Emergency admin access. A built-in bypass lets an admin get back in even if SSO is misconfigured — through a constant in wp-config.php or a pre-set bypass key.
• Open and original. A clean-room, from-scratch implementation you can read and audit.

Connect it to your identity provider

• One-click sign-in via SSO — let users log in through your IdP instead of, or alongside, the WordPress login form, with optional single logout that signs them out of both at once.
• Multi-IdP support — connect several identity providers and let users pick with a login button or a simple ?idp=slug link.
• Encrypted logins handled out of the box — including the encryption that modern providers (such as NetIQ Access Manager) turn on by default and that stock PHP can’t unwrap on its own, so encrypted sign-in just works.
• Attribute mapping — map fields from your IdP (name, email, display name, and custom user data) straight onto WordPress profiles.

Control who gets in, and what they see

• Powerful role mapping — automatically assign WordPress roles based on a user’s groups or attributes, with exact, contains, or regex matching, per-IdP rules, a default-role fallback, and an option to deny anyone who doesn’t match. A built-in safeguard means SSO won’t hand out admin-level roles unless you explicitly allow it.
• Account linking — connect a first SSO login to an existing WordPress account by email (administrators are never auto-linked, for safety).
• Page and content access control — restrict pages, posts, and custom post types to chosen roles or to “logged in via SSO” users, with a per-page editor control, the handy [oasso_restrict] shortcode, and category/tag-level rules. The same protection also covers the REST API, feeds, and oEmbed, so restricted content doesn’t leak through a side door.
• Protected files and blocks — keep uploaded files behind a role check, and show or hide individual Gutenberg blocks by login status or role.
• Email-domain and redirect rules — limit SSO sign-in to approved email domains and send users to the right place after login, per IdP.
• WooCommerce integration (optional) — map attributes to billing and shipping details and auto-link customers by email; loads only when WooCommerce is active.

Stay in control after go-live

• Certificate monitoring — track your IdP’s signing-certificate expiry, get warned before it changes, detect rotation on a daily or weekly check, and optionally pin a certificate for change control, with manual, auto-trust, grace-period, or require-approval handling.
• Searchable audit log — a database-backed, filterable record of who signed in and when, with CSV export and a retention period you set.
• Force-SSO with a safety net — require SSO across the site while keeping an emergency way back in (a constant in wp-config.php or a pre-set bypass key), so a misconfiguration doesn’t leave you stranded.
• Import / export — back up or move your entire configuration as a single JSON file.

Easy setup, no coding

Add your identity provider three ways — upload its metadata XML, paste a metadata URL, or type the details in by hand — then register your site with the IdP using the SP metadata it generates for you. It’s all in the WordPress admin. (Developers also get a documented, stable hook API when they want it.)

Privacy you can verify

The plugin keeps to itself. The only time it reaches out to the network is when you ask it to fetch your IdP’s metadata from a URL, plus an optional, off-by-default certificate-rotation check that re-fetches that same address you entered. It never contacts the author or any third party, and every setting stays in your own site’s database. The two bundled libraries it relies on (both MIT-licensed) make no network calls at all.

Security without the homework

Incoming logins are fully validated before anyone is signed in — the plugin checks the digital signature, the sender, the intended audience, expiry, and replay protection, and accepts only strong, modern cryptography by default. Your SP private keys are encrypted at rest, and the public endpoints are guarded against common abuse. Sensible, secure defaults are on out of the box; the deeper knobs are documented for the rare cases you need them.

Free and open-source

Open Access SSO is licensed GPLv2 or later, with the full source available on Codeberg. There is no premium edition and nothing to buy — what you install is the complete plugin. Its only third-party libraries (xmlseclibs and phpseclib, both MIT-licensed) are bundled and make no network calls.

Requirements

• WordPress 6.0 or newer
• PHP 8.1 or newer
• A SAML 2.0 identity provider you control or have access to

Documentation

Full guides, setup walkthroughs, and hardening advice live on Codeberg:

• Full README / technical reference — https://codeberg.org/idgold/open-access-sso
• Identity-provider setup guide (Entra ID, Okta, NetIQ Access Manager, and more) — https://codeberg.org/idgold/open-access-sso/src/branch/main/docs/identity-provider-setup.md
• Security & hardening guide — https://codeberg.org/idgold/open-access-sso/src/branch/main/docs/security-and-hardening.md
• Troubleshooting guide — https://codeberg.org/idgold/open-access-sso/src/branch/main/docs/troubleshooting.md

External Services

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.

Identity Provider metadata fetch

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.

SAML single sign-on flow

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.).

Roadmap

Open Access SSO is actively developed. Here’s what’s planned next.

Coming next: OpenID Connect (OIDC)

Single sign-on with OpenID Connect identity providers, alongside the existing SAML 2.0 support — connect to OIDC-based providers using the same role mapping, attribute mapping, and access-control features you already use for SAML.

Under consideration

• Automated user provisioning and deprovisioning (SCIM)
• Scheduled group-to-role synchronisation
• A branded identity-provider chooser for sites with multiple providers
• Multi-factor authentication step-up hints
• Deeper WooCommerce customer field mapping

Have a feature request? Open an issue on the project repository.