Single Sign-On (SSO)
Single Sign-On (SSO) for logging in to a WordPress site can be enabled using any identity provider (IdP) that supports Security Assertion Markup Language (SAML). Most IdPs can support SAML.
VIP does not support other SSO technologies for WordPress logins at this time, and cannot install any middleware required in some Shibboleth configurations.
Note
Jetpack SSO is supported and can be enabled on WordPress sites on the VIP Platform. Refer to Jetpack’s documentation for more information about enablement and custom setting options.
Requirement
WordPress sites with SSO enabled must provide a method of site access for VIP Support in order for VIP to provide comprehensive support for an application.
Set up the Identity Provider (IdP)
SAML IdPs require that the VIP application is registered as a service provider. SAML IdPs have different ways of approaching this but the steps are generally:
- Set up the application as a legitimate service provider. Setting up the SAML IdP requires:
- Tell the IdP where and how to communicate with the VIP application.
- Generate the certificate and URLs the IdP will use to send and encrypt communication with the VIP application.
Documentation for creating custom applications for some common IdP’s:
Setting up the SAML IdP requires:
- The ACS location: This usually follows a format similar to
example.com/wp-login.php?saml_acs(where “example.com” is the site’s domain). - The entity-id:
php-saml
Once the SAML application is created, the IdP will provide the following:
- Entity ID (a unique URL)
- Single Sign-on URL
- X.509 Certificate to setup WordPress.
Set up the WordPress site
A plugin to support SAML will need to be added to the WordPress site. The IdP may be able to provide further support or recommend a specific plugin that can be used.
Settings on the WordPress site must meet the following requirements:
- Configure the SSO plugin to create local user accounts.
- If SSO is forced for all users, provide a way for VIP Support users to circumvent the SSO flow on login.
- If SSO is forced on all pages of the site, expose the XML-RPC endpoints to Jetpack requests.
Providing a url parameter such as wp-login.php?normal is the simplest method for allowing users to circumvent the SSO flow and directing them to the WordPress login portal. A more secure method is to only allow access to the WP login portal by requests made from VIP’s proxy servers using the is_proxied_request() helper function to verify the requests.
Two-factor authentication (2FA)
By default, the Two-Factor Authentication (2FA) plugin is active on all WordPress sites on the VIP Platform. 2FA is enforced for all users that have an Editor, Administrator, or Super Admin (WordPress multisite) role.
In some situations, the enforcement of 2FA will need to be disabled for all users in order to successfully enable SSO for a site.
If an SSO plugin is active and configured for a site, the enforcement of 2FA can be disabled for all users by adding the wpcom_vip_is_two_factor_forced legacy filter and setting it to __return_false.
add_filter( 'wpcom_vip_is_two_factor_forced', '__return_false' );A user who already has a 2FA method configured and enabled can authenticate with SSO but will also be prompted to complete the 2FA challenge. Once logged in, the user can disable the 2FA method in their Profile settings page.
Caution
If enforcement of 2FA is code-disabled for all users, the site’s XML-RPC endpoint should also be disabled to maintain site security. To disable the XML-RPC endpoint without blocking necessary calls made by Jetpack, set the XML-RPC Authentication module in the WordPress Security Controls panel to the “Elevated Security” option.
Test SSO configuration
Completing these tests prior to a site’s launch is recommended.
Check users
- Create test users within the IdP, one for each role that is mapped to WordPress to make sure users have the correct role when they sign in.
- Test any known role conflicts to make sure they are resolved as expected.
- Test whether users can successfully log in and out without affecting other SSO sessions in their organization.
Test content protections
- If the entire site requires authentication, make sure clients verify by anonymously accessing the site.
- Make sure all login requests go through the single sign-on process.
Last updated: October 02, 2025