Title: Open Access SSO
Author: idgold
Published: ജൂൺ 17, 2026
Last modified: ജൂൺ 21, 2026
---
Search plugins
# Open Access SSO
By [idgold](https://profiles.wordpress.org/idgold/)
[Download](https://downloads.wordpress.org/plugin/open-access-sso.2.2.0.zip)
* [Details](https://ml.wordpress.org/plugins/open-access-sso/#description)
* [Reviews](https://ml.wordpress.org/plugins/open-access-sso/#reviews)
* [Installation](https://ml.wordpress.org/plugins/open-access-sso/#installation)
* [Development](https://ml.wordpress.org/plugins/open-access-sso/#developers)
[Support](https://wordpress.org/support/plugin/open-access-sso/)
## Description
**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.
## Screenshots
[⌊Open Access SSO dashboard - SSO status, configured Identity Providers, and module
toggles.⌉⌊Open Access SSO dashboard - SSO status, configured Identity Providers,
and module toggles.⌉[
Open Access SSO dashboard – SSO status, configured Identity Providers, and module
toggles.
[⌊Identity Provider configuration - SAML endpoints, signing certificate, and attribute
mapping.⌉⌊Identity Provider configuration - SAML endpoints, signing certificate,
and attribute mapping.⌉[
Identity Provider configuration – SAML endpoints, signing certificate, and attribute
mapping.
[⌊Role mapping rules - assign WordPress roles from SAML attribute values.⌉⌊Role
mapping rules - assign WordPress roles from SAML attribute values.⌉[
Role mapping rules – assign WordPress roles from SAML attribute values.
[⌊Per-page access control in the editor - restrict by role or require SSO login.⌉⌊
Per-page access control in the editor - restrict by role or require SSO login.⌉[
Per-page access control in the editor – restrict by role or require SSO login.
## Installation
1. Download the .zip and upload via Plugins Add New Upload Plugin, or extract into`/
wp-content/plugins/open-access-sso/`.
2. Activate through the Plugins menu.
3. Navigate to **Tools Open Access SSO** to configure.
4. Add an identity provider: upload the IdP metadata XML, paste a metadata URL, or
enter the IdP fields manually.
5. Copy the SP metadata URL shown on the dashboard and register your WordPress site
as a Service Provider in your IdP.
6. Test sign-on using the SSO button on the login page.
## FAQ
### Is it really free?
Yes — completely. There is no premium tier, no license key, and nothing to unlock.
Every feature you read about ships in the GPLv2-or-later codebase: role mapping,
multi-IdP, access control, the audit log, WooCommerce integration, all of it. The
full source is on Codeberg, so you can see exactly what you’re installing.
### Will it work with my identity provider?
Almost certainly. Open Access SSO speaks standard SAML 2.0, so it works with any
standards-compliant identity provider — Microsoft Entra ID (Azure AD), Okta, OneLogin,
Keycloak, ADFS, Shibboleth, and NetIQ Access Manager (now OpenText), among others.
There’s no built-in or default IdP; you bring your own, and you point the plugin
at it. The identity-provider setup guide (see Documentation) walks through the common
providers step by step.
### Do I need to be a developer to set it up?
No. Setup is point-and-click in the WordPress admin. You add your identity provider
one of three easy ways — upload its metadata XML file, paste a metadata URL, or
type the details in by hand — then copy the SP metadata the plugin generates and
register your site with your IdP. No code required for normal use. (If you _are_
a developer, there’s a documented, stable hook API waiting for you.)
### Is my users’ data safe, and does it track anyone?
Yes, and no tracking whatsoever. The plugin has no telemetry, no analytics, no “
phone home,” and no external CDN. The only time it ever 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 plugin author or any third party, and every setting stays
in your own site’s database. Sign-ins are validated end to end before anyone is
let in, and your SP private keys are encrypted at rest. For the full details, see
the security & hardening guide in Documentation.
### What if SSO locks me out?
You have a built-in emergency way back in. You can either add `define( 'OASSO_BYPASS',
true );` to `wp-config.php` to switch off forced SSO entirely, or set a Bypass Secret
Key on the dashboard ahead of time and visit `/wp-admin/?oasso_bypass_key=YOUR_KEY`
to get back in without touching any files. The key route is rate-limited per IP
address to frustrate brute-force guessing. The troubleshooting guide (see Documentation)
covers recovery in detail.
### Can I use more than one identity provider?
Yes. Configure as many IdPs as you need under Tools Open Access SSO Identity Providers.
Your users pick the right one with a button on the login page or via a simple `?
idp=slug` link.
### Can I assign WordPress roles automatically from my IdP?
Yes — that’s one of the headline features. Map WordPress roles from the groups or
attributes your IdP sends, using exact, contains, or regex matching, with per-IdP
rule sets, a default-role fallback, and an option to deny anyone who doesn’t match
a rule. For safety, SSO won’t grant admin-level roles unless you explicitly turn
that on, and existing administrator accounts are never auto-linked to an SSO login.
### Does it support encrypted logins?
Yes, out of the box — including the modern encryption that some providers (such
as NetIQ Access Manager) turn on by default and that stock PHP can’t unwrap on its
own. The plugin bundles a small MIT-licensed library to handle exactly that, so
encrypted sign-in just works where a plain PHP setup would fall short. Encrypted
user identifiers are supported too.
### Does it work with NetIQ Access Manager?
Yes. NetIQ Access Manager (now part of OpenText) is a standard SAML 2.0 identity
provider and is fully supported, including its default encrypted assertions. One
clarification: NetIQ _Identity Manager_ (sometimes called “IDM”) is a separate user-
provisioning product, not a SAML IdP — it’s Access Manager that acts as the identity
provider here.
### Can I keep an eye on certificates and sign-in activity?
Yes. The plugin tracks each IdP’s signing-certificate expiry and can warn you before
it changes, detecting rotation on a daily or weekly check with your choice of manual,
auto-trust, grace-period, or require-approval handling — and you can pin a specific
certificate if you want strict change control. A searchable, database-backed audit
log records who signed in and when, with CSV export and a retention period you set.
### Is this related to the old “OpenSSO” product from Sun or Oracle?
No. Open Access SSO is an independent open-source project. It is not affiliated
with, and is not a continuation of, Sun Microsystems’ or Oracle’s discontinued “
OpenSSO” product — the similar name is coincidental.
## Reviews
ഈ പ്ലഗിന് റിവ്യൂകൾ ഒന്നുമില്ല.
## Contributors & Developers
“Open Access SSO” is open source software. The following people have contributed
to this plugin.
Contributors
* [ idgold ](https://profiles.wordpress.org/idgold/)
[Translate “Open Access SSO” into your language.](https://translate.wordpress.org/projects/wp-plugins/open-access-sso)
### Interested in development?
[Browse the code](https://plugins.trac.wordpress.org/browser/open-access-sso/),
check out the [SVN repository](https://plugins.svn.wordpress.org/open-access-sso/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/open-access-sso/)
by [RSS](https://plugins.trac.wordpress.org/log/open-access-sso/?limit=100&mode=stop_on_copy&format=rss).
## Changelog
#### 2.2.0
* Security (Force SSO): when Force SSO is enabled it is now enforced at the authentication
layer, not just on the login page. Native username/password sign-in (including
over XML-RPC) is rejected, and Application Passwords and XML-RPC are disabled,
so a leftover local password, an XML-RPC client, or an Application Password can
no longer bypass single sign-on and the central deprovisioning and MFA it provides(
CWE-287). The emergency bypass still restores local access (the `OASSO_BYPASS`
wp-config constant or the bypass secret key), and sign-in is never enforced while
no Identity Provider is enabled, so a misconfiguration cannot lock you out.
* New: two opt-in settings under General Settings, both off by default — “Allow
Application Passwords” and “Allow XML-RPC” — re-enable those API surfaces while
Force SSO is on, for a site that relies on a trusted integration. Re-enabling
XML-RPC also restores its username/password (basic) authentication, the classic
brute-force surface, so leave it off unless a legacy integration needs it.
* Hardening: the SSO error message shown on the login screen after a failed sign-
in is now carried by a short-lived signed token, so an arbitrary `?oasso_error
=` value can no longer suppress the Force-SSO redirect or render chosen text
on the login page.
* Note: this does not change a site that does not use Force SSO. Real SSO sign-
in, the bypass paths, and existing logged-in sessions are unaffected.
#### 2.1.5
* Security (access control): restricted media and posts no longer leak through
secondary read paths. The REST media endpoint now hides a restricted attachment’s
metadata and real file URL, including when the restriction is inherited from
the attachment’s parent post (CWE-639); and restricted posts are excluded from
REST search results and the XML sitemap (`wp-sitemap.xml`) for visitors who are
not allowed to see them (CWE-200).
* Security (media): new optional “Require SSO for the protected directory” setting
under Access Control (off by default). When enabled, files in the protected uploads
directory may be downloaded only by users who signed in through SSO — enforced
on both the `oasso-protected/` and `oasso-file/` delivery routes (CWE-276).
* Security (SAML replay): the replay-protection record for a consumed assertion
now lives at least as long as the assertion’s own validity window, closing a
small window in which a captured response could otherwise be replayed after the
record expired (CWE-294). The record lifetime is capped to a safe maximum.
* Hardening: SSO attribute mapping can no longer write to WordPress privilege or
session storage keys (`wp_capabilities`, `wp_user_level`, `session_tokens`, and
their multisite variants), even if such a mapping is configured — refused at
both the settings save and the login write.
* Fix (multi-IdP): when more than one Identity Provider is configured, an SSO response
is now matched to the correct IdP by its Issuer before signature verification,
instead of assuming the first enabled IdP. This restores sign-in for a non-first
IdP whose response would otherwise be verified against the wrong certificate.
* Change: SSO now auto-creates a WordPress account only when an email address can
be resolved from the Identity Provider’s attribute mapping. It no longer guesses
the email from the NameID or from loose attribute keys, because what a new account’s
email should be is the administrator’s mapping decision. The default SAML email-
claim mapping still applies, so conventional IdPs are unaffected; if accounts
stop being created after upgrading, map an email attribute to the email field
in that IdP’s Attribute Mapping.
* Fix (diagnostics): when a user cannot be created because no email address could
be resolved from the assertion (for example, the IdP’s email attribute is not
mapped to a WordPress field), the debug log now records an actionable reason
that names the attributes the IdP sent and points to the Attribute Mapping, instead
of a generic “could not create user” message.
* The new access-control setting is off by default; the bundle also refreshes the
plugin documentation and listing.
#### 2.1.4
* New: support for IdPs that encrypt the assertion session key with RSA-OAEP using
a SHA-256 (or SHA-384/512) digest, via the bundled phpseclib library. PHP’s OpenSSL
only unwraps RSA-OAEP with SHA-1; the plugin now honours the exact OAEP digest
declared in the encrypted assertion, so encrypted-assertion SSO works with NetIQ
Access Manager and other IdPs that default to OAEP-SHA-256. AES-CBC/GCM data
decryption is unchanged.
* Security (DoS): all SAML XML parsers now reject documents carrying a DOCTYPE /
inline DTD, closing an unauthenticated XML internal-entity-expansion denial-of-
service reachable at the ACS/SLO endpoints before signature verification (CWE-
776). Inbound SAML messages are size-capped before decoding and DEFLATE-compressed
redirect-binding messages are inflated with a bounded buffer, closing a decompression-
bomb DoS (CWE-409). The cap is filterable via `oasso_max_saml_message_bytes`.
* Security (encryption): encrypted-assertion and EncryptedID decryption now checks
the key-transport and data-encryption algorithms against an allowlist before
any decryption runs — RSA-OAEP for key transport (RSA-1.5 refused) and AES-CBC/
GCM for data (TripleDES refused), mirroring the signature-algorithm allowlist(
CWE-780/327). Legacy RSA-1.5 / TripleDES can be re-enabled only via the import-
only `allow_legacy_decryption_algorithms` setting (off by default), and any such
acceptance is audit-logged.
* Security (assertions): an assertion must now carry an enforceable expiry boundary(
a `Conditions` or bearer `SubjectConfirmationData` `NotOnOrAfter`); one with
none is rejected (CWE-613). The new “Require assertion expiry” Service Provider
setting (on by default) lets you relax this for a non-conforming IdP.
* Security (admin): IdP-supplied SAML attribute names shown in the redirect-rule
editor are now HTML-escaped at the rendering sink and hex-encoded in the inline
configuration, closing a stored DOM cross-site-scripting issue a malicious or
compromised IdP could trigger in an administrator’s browser (CWE-79).
* Security (audit export): audit-log CSV export now neutralises spreadsheet formula
triggers (a leading `=`, `+`, `-`, `@`, tab or carriage return, plus their full-
width Unicode variants) in IdP-controlled fields, preventing CSV / formula injection
when an exported log is opened in a spreadsheet (CWE-1236).
* Maintenance: non-Success SAML responses now surface the nested `StatusCode` and`
StatusMessage` for clearer diagnostics, and the SP metadata advertises the supported
assertion-encryption algorithms (RSA-OAEP key transport, AES-GCM/CBC data) for
IdPs that consume them.
#### 2.1.2
* Security: SSO no longer assigns administrator-level roles (any role carrying
capabilities such as `manage_options` or `edit_users`) unless you explicitly
enable the new “Allow Administrator-Level Roles via SSO” setting in General Settings(
off by default). This prevents a role-mapping rule from silently elevating an
auto-provisioned SSO user to a role that can take over the site. Users who would
have received such a role get the default role instead. If you deliberately map
an IdP identity or group to an administrator-level role, enable this setting;
the configuration importer enables it automatically when an imported config already
maps to such a role.
* Fix: term (category/tag/custom taxonomy) restriction fields now authorise against
each taxonomy’s own editing capability via the `edit_term` meta capability, instead
of a hardcoded `manage_categories`. Custom taxonomies that use their own capabilities
now save restriction settings correctly.
#### 2.1.1
* Security hardening (SAML signature handling): the IdP’s signature algorithm is
now read before XML-DSig reference processing and checked against an explicit
allowlist of RSA algorithms (RSA-SHA256/384/512; RSA-SHA1 only when the SHA-1
fallback is enabled). This makes the protection against signature-algorithm confusion
explicit and robust, and lets IdPs that sign with RSA-SHA384/512 verify (previously
only RSA-SHA256 was accepted). The same SHA-1 opt-in now also gates Redirect-
binding signatures.
* Security hardening: the assertion-level `Issuer` is now required and must match
the configured IdP, and assertions must carry an `AudienceRestriction` naming
this Service Provider. A new “Require audience restriction” Service Provider
setting (on by default) lets you relax the audience check for an IdP that legitimately
omits it.
* Fix: the Service Provider screen showed outdated `?ossa=acs` / `?ossa=slo` URLs;
it now shows the correct `?oasso_acs=1` / `?oasso_slo=1` endpoints. Removed a
non-functional metadata “Download” button (copy the metadata from the field shown
instead).
* Maintenance: uninstall now also removes term-level restriction settings; the
optional certificate-rotation cron is documented in the External Services section;
assorted internal identifier and PHP-requirement cleanups.
#### 2.1.0
* WordPress.org review compliance: the plugin’s internal prefix was renamed from
the 3-character `oas_` / `OAS_` to `oasso_` / `OASSO_` across all options, hooks,
transients, cron events, user/post meta, AJAX actions, nonces, asset handles,
and custom tables. The PHP namespace (`OpenAccessSSO`) and plugin slug (`open-
access-sso`) are unchanged.
* The content-restriction shortcodes are renamed `[oas_restrict]` `[oasso_restrict]`
and `[oas_login_button]` `[oasso_login_button]`.
* Security: the `[oasso_restrict]` shortcode now passes its returned content through`
wp_kses_post()`.
* Security: the admin “Test Connection” link now carries and verifies a nonce.
* **Because the internal prefix changed, this is NOT a drop-in upgrade. Export
your configuration first, then reinstall and re-import — see the Upgrade Notice
below for the exact steps.**
#### 2.0.4
* Maintenance release addressing WordPress.org plugin review feedback. All inline
scripts and styles are now delivered through the WordPress enqueue APIs (`wp_add_inline_script`,`
wp_add_inline_style`, `wp_get_inline_script_tag`) or a linked stylesheet, instead
of raw `