Advocate Single Sign-On

What is Single Sign-On? 

Single Sign-On (SSO) eliminates the need for users to “sign on” more than once when accessing any VoterVoice module that is embedded into the client website that employs a sign-on page. 

This feature adds a level of convenience but can also add a security layer when a customer provides access to our system exclusively from behind a members-only website. Without SSO, if a user signs on to the customer website, that sign in is valid only for pages hosted on the client’s website. The VoterVoice system will not know who that user is until he/she also signs on to the VoterVoice system. The user would need to sign on twice during the same session: once for the client site and once for the VoterVoice module. 

SSO solves this problem by allowing the client’s web developers to embed a special ID into the URL whenever they create a secure link to the VoterVoice site from the client website. This special ID will always be the unique ID of the user who would otherwise need to sign on. This unique ID should first be created in the client’s internal (non-VoterVoice) database, and that unique ID must also be present in the VoterVoice database (this can be done in real-time using our API or uploaded through Datasync or manually prior to the user’s access). When this unique ID is presented, the VoterVoice system will look into the VoterVoice database for the user who matches that ID. If a match is found, the user will be authenticated; and his/her information will be displayed. 

Enabling Single Sign-On

SSO is not enabled by default. Your VoterVoice Account Manager can enable this feature for you on request. 

Authentication Levels 

There are two types of access we can provide with SSO: “Convenience” or “Security.” 

The Convenience​ setting means the VoterVoice system remains open to the public, as it is by default. Under the Convenience setting, SSO is a way for the user to avoid signing on twice if they have already been authenticated on the client website. If they have not been authenticated, and therefore by definition not using SSO, the user will still be allowed to access VoterVoice modules. Users can type in the URL for the VoterVoice action center directly and get in and take action even though they were not logged into the client’s website. Even if users forward the link to the VoterVoice action center to their friends, those friends can join in and take action, helping the organization build its supporter list virally. Most VoterVoice clients who have SSO enabled use this setting. 

The Security​ setting means that a user MUST first to be authenticated by the client website before they will be allowed to use the VoterVoice system. The user cannot just go to “http://www.votervoice.net/GroupXYZ/Campaigns” and take action. Without this setting enabled, the VoterVoice system is open to anyone who wants to participate (as long as they know the web address). The SSO Security setting, however, will limit those allowed to use the VoterVoice system to only those users who have signed on to the client’s website first. 

Most clients with SSO enabled do not use this setting, as it is much more restrictive and will hinder the organic growth of your list. 

Implementing Single Sign-On 

The SSO functionality should be simple for the client’s web developer to implement. Any link to the VoterVoice system from a page on the client’s website will need a parameter added to the URL string. For example, if the VoterVoice page you want the user to access is 

https://www.votervoice.net/DEMO/Campaigns 

Then to add the SSO functionality, the customer’s web developer would simply add the ContactID=[unique id]​ and the VVACCESSID​ to that string. So it could read, for example: 

https://www.votervoice.net/DEMO/Campaigns?ContactID=ABC12345678​&VVACC ESSID=7c1a6c4e-9a92-11df-bb86-12313b048a32 

The ContactID is the unique ID for that user. It is the same alphanumeric string that will be in the ContactID field in the VoterVoice database. The VVACCESSID is the unique key identifying your organization. It is case-sensitive and should never change. The unique ContactID needs to be hashed and/or hidden from users at all times. If the unique ContactID is hashed when sent to VoterVoice, the unique ContactID will also need to use the same hash when stored within the VoterVoice database. 

Using these values, the VoterVoice system will match the user to the record in the VoterVoice database and automatically fill in his/her contact info where necessary.

These parameters must be added to a VoterVoice URL directly or they will not work. You cannot, for example, apply these parameters to a URL on your own domain. 

VoterVoice API 

Organizations that need real-time integration of new user sign-on will need to use our API. Without the API call, the VoterVoice system can only authenticate users who have been previously uploaded to the VoterVoice database. These data uploads are normally done daily or less frequently. This works fine for some organizations that don’t add users on their website. But some organizations allow users to sign up for the first time on their website. For this type of organization, there may be a time lag between a new user signing up on their website and the new user’s information being updated in the VoterVoice database. 

To solve this problem, the client’s website developers can use the VoterVoice API. This web service enables the customer to pass the new user’s contact information to the VoterVoice system within seconds of the new user signing up. The documentation for the REST API can be found here.