Multiple Authentication Sources


Depending on who is using your site and how they’re coming to it, you may have several authentication sources feeding into your site, all at the same time.

You can use any or all of the following sources, simultaneously:

If you're considering multiple authentication sources for your organization, contact us at before you begin.

Login Process with Multiple Authentication Sources

When your site has multiple authentication sources enabled, it’s important to provide clear instructions about how to log in. Otherwise, your users might be confused or accidentally create new accounts on the wrong source.

You should take a few simple steps to minimize this confusion.

Give your sources names users will recognize

When your users come to your site, they will be asked to select which source they’ll be using to log in. The average user probably won’t be familiar with terms like “Single Sign-On,” so it’s important for you, as the site administrator, to assign recognizable nicknames to every source you have enabled.

The settings page for each authentication source includes a field for Name. (On some sources, like OpenID and Site Password, this will be the only field.)

While you can edit these names at any time, it would be better to put some thought into naming them correctly the first time, and avoid any possible confusion over replacing names that your users have become accustomed to.

Post clear instructions where your users need them

If you suspect your users still might have some trouble selecting the appropriate login option, you can post instructions for them on the login pages.

Go to Site Administration > Settings > Content Manager. You can create new content for any of these parts of your site, just like you would edit a wiki page. In particular, you might want to add clear instructions to three of these Content Manager options:
  • Site Account Creation: This content appears whenever a visitor to your site is given a form that will let them request a new user account on the Site Password authentication source. This includes the Join page and some permission denied pages.
  • Site Sign In: This content will appear above your site’s sign in options anytime a visitor is trying to log into your site (including access restricted pages and the main site sign in form). It is a good place to explain your different login options and direct you users to select the appropriate one.
  • Site Sign In, Main Introduction: This content will only appear on your main sign in page, above the content you’ve defined for Site Sign In. It is a good place to add a welcome message, general instructions, and, if Site Password is one of your enabled authentication sources, a link to the Join page.

Use Cases

Here are a few examples of situation is which you might want to use multiple authentication sources:

Scenario 1

You have just started a Private Label site for your school district. You already have one LDAP directory for the local high school, and another for the local middle school. You want to use both directories for students and teachers, and you still want the be able to assign usernames and passwords to parents — without adding them to either LDAP directory.

You can easily add both LDAP directories as authentication sources, and keep your Wikispaces Passwords source active for parent user accounts.

Scenario 2

Your university is setting up a Private Label site. Naturally, you want to integrate the site with your university-wide authentication system, so your students, faculty, and staff have Single Sign-On access to the site. But you’re also aware that your professors will want to collaborate with experts and colleagues from outside your university.

Leaving your SSO source active and in place, you can also activate the Wikispaces Password source and assign usernames and passwords to external collaborators. Or you can enable OpenID, so that anyone with an OpenID account can request an account through their OpenID URL.

Caveats and Potential Conflicts

Naming Conflicts

Most of the time, if someone tries to create an account with a username that is already associated with an existing user, they will be informed that the name is already taken and instructed to select another. However, there is an exception to this: In the event that two users have been created on different authentication sources with the same username, a Single Sign-On source takes precedence over Wikispaces Password.

For example, if you have a user in your SSO system named Green01, someone could create a Wikispaces Password user named Green01 before the SSO user has logged in for the first time. In that situation, when the SSO user does log in, he will create a Wikispaces account under the Green01 username. The Wikispaces Password user account will be renamed, and she will be sent a notification.

Mapping and Migrating Users

After you have configured your SSO source but before you have finished migrating any existing users from the Wikispaces Password source, there is a brief window in which a user might log in through the SSO source before their account has been migrated, resulting in a duplicate user in the SSO. While you can fix this later, any changes made by the duplicate user during that time will not be attributed to the correct user. We recommend that you complete your SSO configuration and migration process quickly to keep this window as small as possible.

To make that process as quick and painless as possible, we also recommend that you map your users before you begin the configuration process. You will want to rename all your Private Label user accounts to match the usernames on your authentication server before you turn on SSO. If this is a larger list than you can reasonably rename by hand, email us at and we’ll rename them for you.

Usernames on Wikispaces must be between 3 and 32 characters long and contain only letters (a–z and A–Z); numbers (0–9); and/or the period (.), underscore (_), or hyphen (-) characters. If your usernames do not match the allowed criteria, they must be adjusted. For example, a username of "Mr Jones" might be translated to "Mr_Jones" before being sent to Wikispaces. This can be done through a persistent database mapping on your server, or more easily through a function that replaces invalid characters with valid ones.

Disconnected Mode

In most cases, you will want to leave the Disconnected Mode box unchecked. However, if your SSO server has an inactivity timeout — meaning that it logs users out whenever they leave the main application — you may want to check the Disconnected Mode box. In disconnected mode, Wikispaces will query the SSO server when the user first logs in, and then cache the result. The user will remain logged in to Wikispaces until they log out or close their browser session.

Still have questions? Send us an email at