SECURITY VS. CUSTOMER EXPERIENCE

Single Sign-On Is Still on CIOs’ Priority Lists

One of the remaining “To-Do’s” on many technology execs’ wish list for the coming year is to finally implement single sign-on for their employees, business partners, and customers. From a customer experience point of view, we all would prefer not to have to re-enter our user IDs and passwords as we move from one application to another within the same session and/or when interacting with a single organizational entity.

Employees want to be able to logon once to their corporate intranet, and/or to an employee portal, and, from there, gain access to all the information, resources, and applications to which they’re entitled. Customers don’t want to have to logon anew each time they deal with different parts of our organizations.

A number of businesses have already invested in and delivered single sign-on to their customers. Fidelity Investments bit the bullet last year when its customers began complaining about the fact that they had to log-in separately to access their personal accounts and their company-sponsored retirement accounts. So Fidelity implemented a single sign-on service. Today, if you have a retail brokerage account at Fidelity Investments and you also have a 401K retirement account at Fidelity, you can move back and forth among your accounts with a single secure logon.

Yet, at Wells Fargo, another leading financial services institution, consumers may still encounter separate log-ins for different consumer product lines, such as mortgages and deposit accounts. Wells Fargo, like many other organizations, is making single sign-on a high priority this year.

In the healthcare and health insurance industries, single sign-on is also high on the priority stack, in part due to the requirement to implement HIPAA-compliant (Health Information Portability and Accountability Act) applications in the U.S. Doctors and other care-givers, patients, and insurance providers, all need to be able to logon securely to a variety of patient-impacting information sources and applications and to be able to share that highly-confidential information with patient-approved parties.

Implementation Is Still Too Tough, Particularly in Multi-Party Contexts

The technologies and services that are currently being used to implement single sign-on within our enterprises are still too complex. Single Sign-on often takes a long time to implement. It requires lots of application integration. And that’s just within the enterprise.

DO PORTALS HELP REDUCE THE COMPLEXITY OF IMPLEMENTING SINGLE-SIGN ON?

We believe that one of the reasons for the explosive growth in portal deployments is the fact that portals are supposed to ease the single sign-on burden. If you design each portal for a specific constituency (employees, partners, customers, suppliers, salespeople, HR administrators, etc.), then you can implement single sign-on at the portal level. You can administer the log on privileges for each group of users at the portal level, rather than at an application-by-application level. This is perceived to be one of the benefits of rolling out portals.

Here’s the rub. As David Marshak points out in his Portal Q&A, many portals are designed to give users access to applications and services that are actually administered by external service provides or by other third parties. Take health insurance, for example. In the U.S., an employee typically accesses his/her health insurance benefits from within his company’s employee portal. These benefits are typically administered by one company (e.g., Hewitt), provided by several other companies (e.g., Blue Cross Blue Shield for health benefits, Delta Dental for dental care, Medco for prescription benefits, and so on). Suddenly, the single sign-on requirements for each employee have mushroomed. Instead of giving each employee secure access to a set of internal applications and files within your firewall and within your company, your employee portal needs to give each employee secure access to applications and files that are hosted by third parties with complex rights and permissions.

Single sign-on is going to remain an elusive goal for many organizations throughout 2003. Implementation of single sign-on across applications and organizational boundaries needs to get a lot easier. Customers expect secure, yet easy and efficient access to all the information and applications they need to complete each of their scenarios.

WEB SERVICES EXACERBATE THE COMPLEXITY OF SINGLE SIGN-ON. One of the bits of architectural good news in 2002 is the coming together of portal architectures and Web Services. Most portal suppliers are standardizing on Web Services interfaces for application integration and portlet creation. Yet, as we move towards service-oriented architectures, single sign-on and authentication becomes even more complex. A customer wants to log onto a portal and begin a scenario which may launch service requests to a variety of applications both within and outside his organization. Each of these service requests needs to be re-authenticated at the application level and at the file level to ensure that the end-requestor, and the services acting as that person’s proxy, have the rights and permissions required to access the requested functions and information.

Achieving the holy grail of single sign-on is not a simple task. We offer examples of best practices from companies that have implemented single sign-on in complex multi-party relationships.