Single Sign On (SSO, not to be confused with Jetpack SSO) is possible for VIP sites using any identity provider (IdP) that supports Security Assertion Markup Language (SAML). VIP does not support other SSO technologies at this time, and cannot install any middleware required in some Shibboleth configurations. Most IdP’s can support SAML.
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.
Setting 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 purpose is to:
- Set up the application as a legitimate service provider
- 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, usually
example.com/wp-login.php/?saml_acs(where “example.com” is the site’s domain)
- The entity-id:
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.
Setting 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.
The easiest way is to allow users to circumvent the SSO flow is to provide a url parameter like
wp-login.php?normal that directs users to the
wp-login form. A more secure way is to detect if a user is accessing the site through VIP’s proxy servers.
OneLogin’s WordPress SAML plugin
OneLogin’s WordPress SAML plugin works with any IdP and is managed through a settings page where you can fully configure your application. If you’re using this plugin, make sure you also have our helper plugin installed to the client-mu-plugins directory which takes care of some of the required details above and also ensures cookies and other SSO settings pass through our cache layers.
Options and Settings
You can mostly choose how to configure your own SSO. Some settings may be dictated by the IdP. If you’re doing a lot of custom configuration, we highly recommend you thoroughly test your SSO setup on your VIP application before launch.
Suggested settings available under the “Options” heading of the OneLogin plugin:
- Create user if non exists: This causes WordPress to create local accounts for users that sign in over SSO. (Required)
- Update user data: This causes user attributes like first name, last name, and email address to change on WordPress when they change in your IdP. (Recommended)
- Single Log Out: Only useful if the client’s IdP supports it. (Not recommended)
- Alternative ACS Endpoint (Not supported)
- Match WordPress account by: Choose how to match users to their IdP accounts.
Preventing unauthenticated site access with SSO
The “Force SAML Login” option can be enabled in order to make a VIP site “private” is by requiring SSO authentication to access any page on an entire site. A method for VIP Support to circumvent SSO to access the site should be provided.
Requiring SSO to login
Creating local accounts on the WordPress install are required so that VIP Support can more easily troubleshoot when users are having issues. This does not prevent the customer from requiring SSO to log in. If the customer requires SSO for all logins from their users, enable the following options in the OneLogin plugin’s settings:
- Prevent reset password: This will prevent users from resetting their WordPress account passwords.
- Prevent change password: This will prevent users from changing their WordPress account passwords.
- Prevent change mail: This will prevent users from changing the email address in their WordPress account profile.
Testing SSO configuration
Completing these tests prior to a site’s launch is recommended.
- 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.