Single Sign-On Overview

As of 7.4.1, the WEB_USER table has been deprecated and SSO is required for Personify e-Business site login. For more information, please see Customer Creation and SSO. If your organization has customized the WEB_USER table for any other reason, please contact your Account Specialist for future considerations.

Single Sign-On (SSO) is an application developed by Personify primarily for associations to integrate different vendor sites. Using SSO, associations can provide a seamless experience to their members for connecting to other vendors’ websites. Starting Personify 7.4.1, SSO will also be the only source of authenticating a user in Personify e-Business.

 

Personify Single Sign-On provides a means for organizations to facilitate movement of their members and customers between their organization website and the websites of their third-party vendors and partners.

 

An association member’s current Web experience can include dealing with multiple websites maintained by multiple third-party vendors. Although these websites can be interlinked and can provide access to each other via links, they usually have their own logic for authenticating users. As a result, an association’s members and customers have to log in separately to each site.

 

Personify SSO provides associations and their vendor websites with a single sign-on (login) service, eliminating the need for separate logins and providing users with a personalized and seamless interface across the sites. A centralized database stores and maintains the required login information for the users for each website. Web services interact with this database to provide an Internet interface that allows websites to request login and other authentication data. All sites must implement an interface to call the centralized web services. The Personify database is the primary source for member and customer information for associations, including demographics information and web access-related data (i.e., user IDs and passwords).

 

Using SSO, a website will send a request to the web service when a user first attempts to log into the site. If a user goes to another participating site after logging in, the new site sends a request to the web service and receives confirmation that the user is already logged on, maintaining the common login. Sites also interact with the web service by automatically updating user information if it changes on any participating site.

 

In addition, SSO can be used with any CMS.

 

After completing your SSO integration, a few things need to be remembered:

1.    In order to use SSO, existing customers need to convert to the SSO database.

2.    The VendorCustomerId is case-sensitive.

3.    The Hint Question module is not available when using SSO.

4.    Host/Admin users are not available through SSO. Only Personify customers can log in through SSO. Therefore, a “dummy” customer, representing the host or admin, needs to be created in Personify. TMA Resources recommends you create another tab and inject the DNN Account Login web part “For Host/Admin Only”. This step has to be done before you upgrade to 7.4.1.

 

The Identity Management System (IMS) enhances the member’s experience for both the association’s website and the integrated websites from other vendors. Using IMS, vendors can manage members’ access to the different areas of their websites.

 

The IMS provides real-time information about member identities or their assigned role. Members benefit by getting information from related websites in a timely manner.

 

The key to identity management is to define roles based on business rules. Vendors will use Web services to obtain the roles of a member or customer. Based on the role, the vendors can then manage the workflow for the website.

 

This chapter covers the steps to install the Single Sign-On (SSO) application and the Identity Management System (IMS) application.

All SSO and IMS components are Web applications. For each of these applications there will be separate web.config files. The correct values must be set for all parameters in each web.config file.

As of 7.4.1, the SSO application DOES allow for duplicate email addresses to exist across multiple customer names.

Currently, SSO does not track the last login date and the last time the password was updated.

This section covers the following:

·       Components of Single Sign-On

·       Prerequisites for SSO and IMS

·       SSO Architecture

·       SSO Software Requirements

·       Web Services for SSO

·       SSO and Load Balancing

·       Customer Creation and SSO