Security (media relocation): protected media files are no longer left in the public uploads directory. The moment a page or post carrying attached media becomes restricted, its files are physically moved into a private, unguessable directory outside the public web path and served only through the access-checked media gateway, closing direct-URL access to a protected file’s original public path even if the URL is bookmarked or cached elsewhere (CWE-284). Unprotecting the content, or uninstalling the plugin, moves the files back to their original locations.
New: files that were already protected before upgrading to 2.4.0 are left in place until you act. A “Relocate existing protected media (N)” button under Access Control migrates them in batches, without interrupting the site.
New: the media gateway now serves resized image variants (not just the original file), streams video with HTTP Range support for seeking, and honours conditional requests (If-None-Match / If-Modified-Since) so browsers and caches skip re-downloading unchanged files.
New: two health checks under Access Control — a relocated file’s leftover public copy (“source residue”) and orphaned working directories left by an interrupted relocation — each with a one-click cleanup action. Health items are excluded from the pending-migration count and are left untouched when the migration is re-run.
New: a “Relocate protected media files” setting (Access Control, on by default) turns off automatic relocation for newly-protected content if needed; a server-type readout flags nginx, where .htaccess-based protection of the legacy public path does not apply.
Fail-secure by design: deactivating the plugin makes relocated files unreachable through the gateway, but it never moves them back to a public path or otherwise exposes their new location.
New oasso_media_relocated and oasso_media_restored hooks fire when a file moves into or out of the private directory; both are recorded in the audit log.
Hardened for restrictive managed hosts: on PHP 8 a function listed in the host’s disable_functions is undefined and calling it is fatal — on one such host this crashed the page save (“There has been a critical error on this website”) the moment a restriction change triggered media relocation. All relocation, restore, health-check, and uninstall paths now run inside fail-safe boundaries: a server error can no longer break the page save (or the uninstall), it is recorded in the plugin debug log with the exact cause even when Debug Mode is off, and a persistent, dismissible admin notice names the affected file with retry instructions. The disk-space preflight and the regex rule matchers (role mapping, login redirects) also detect disabled disk_free_space/ini_set and degrade gracefully instead of crashing the save or the SSO login.
Editors keep showing protected images: URLs baked into existing content (the classic editor, the block editor, and page builders render these directly) stop resolving once a file moves to the private area. Requests to such a stale URL from anyone who passes the file’s access rules are now redirected to the media gateway, so editor previews and old bookmarks keep working for authorized users — while unauthorized visitors still get the same plain “not found” response as before, revealing nothing.
2.3.0
Security (certificate pinning): pinning is now anchored to an independent fingerprint recorded when you pin, instead of being recomputed from the stored certificate. Previously the “Auto Trust” and grace-period rotation strategies silently moved the pin together with the certificate, so pinning could not catch an unauthorized certificate swap, for example after a metadata-host takeover (CWE-295). While an IdP is pinned, automatic rotation never replaces its certificate: a new certificate found at the metadata URL is queued for your approval, an email is sent, and a persistent admin notice is shown until you act. Signature verification — for sign-in and logout alike — fails closed if the stored certificate stops matching the pinned fingerprint.
Only explicit administrator actions move the pin anchor: saving the IdP form, approving a pending certificate, or re-importing metadata. Pin changes and blocked rotations are recorded in the audit log (new oasso_cert_rotation_blocked and oasso_cert_pin_changed hooks).
On upgrade, each already-pinned IdP is automatically anchored to the fingerprint of its currently configured certificate, so existing installs keep working with no action needed. Unpinned IdPs rotate exactly as before; nothing changes for them.
UI: the Identity Provider screen now shows the pinned anchor fingerprint, warns when the stored certificate no longer matches it, and warns when “Auto Trust” or “Grace Period” is selected for a pinned IdP (while pinned, those strategies queue new certificates for approval instead of rotating).
Security (sign-in redirect): the HTTP Referer fallback used for the post-sign-in return URL is now validated with wp_validate_redirect(), so a crafted Referer header can no longer place an external redirect target into the SAML RelayState (CWE-601).
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 <script>/<style> tags.
Removed obsolete pre-PHP-8.0 libxml_disable_entity_loader() calls. The plugin requires PHP 8.1+, where libxml ≥ 2.9 already disables external-entity loading by default and LIBXML_NONET blocks network access; the calls were dead code and deprecated in PHP 8.0.
Documented the SAML Identity Provider external-service interaction in a dedicated readme section.
No functional or behavioural change.
2.0.3
Added an optional “support development” link (Ko-fi) in the admin footer of the plugin’s own pages, plus a Donate link in the readme. No functional change; the link opens externally and the plugin makes no network calls of its own.
Compatibility: declared tested up to WordPress 7.0.
2.0.2
PCP polish: WordPress Plugin Check now reports zero findings for the distributable zip. Two real sanitiser additions in the admin settings form; the rest are inline phpcs:ignore annotations with reason comments at intentional sites (cross-origin POST at the SAML ACS endpoint, PCRE limit hardening before user-supplied regex evaluation, table DROP on uninstall, internal-only DB query composition). No behaviour change.
Build: README.md (GitHub-only readme) is no longer shipped in the distributable zip; composer.json is now included so the bundled vendor/ directory is transparent to plugin reviewers.
2.0.1
Fix: Test Connection now populates results and attribute dropdowns reliably regardless of how long the admin has been logged in. The admin’s identity is now recorded at initiate-time in a server-side transient keyed by the AuthnRequest ID, and looked up at the ACS callback via the response’s InResponseTo. The previous flow depended on the WP auth cookie surviving the cross-origin POST from the IdP, which modern browsers block under SameSite=Lax outside a brief carveout window.
2.0.0
Initial release on WordPress.org. (Project formerly known internally as OpenSSO Access; renamed to Open Access SSO ahead of public release.)
Full SAML 2.0 SP with multi-IdP support.
Attribute mapping, role mapping, page access control, WooCommerce integration.
Audit log, force-SSO mode, emergency bypass via OAS_BYPASS.
