Single sign-on can reduce help desk calls and improve the user experience.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
For David Young, information technology program director at Geisinger Health System, it was about improving the customer experience. For Steve Siress, network systems manager for Enterprise Bank & Trust, it was driven by compliance. For Charles E. Christian, director of information systems at Good Samaritan Hospital, it was about increasing the quality of patient care and reducing tedious documentation.
For all of them, single sign-on also helped reduce help desk calls and led to a more positive customer experience.
Organizations have pursued a variety of strategies to simplify, reduce and consolidate multiple application sign-ons, with the goals of improving user experience, reducing costs and improving compliance. Enterprise single sign-on and Web access management systems have become two of the most common and widely deployed solutions in the market today.
The implementation for Young, Siress and Christian were all success stories. But, any rollout can be fraught with setbacks and implementation headaches. Before you decide which approach makes sense for your organization, we'll explain their capabilities and implementation considerations.
WAM registers with hospital
For David Young, Geisinger Health System's information technology program director, using a Web access management solution was a good diagnosis. As a health care provider, the company wanted to improve patient satisfaction and save time and resources by getting patients to update information such as address or insurance changes.
That was four years ago. Today patients can view their medical reports, lab results and schedule doctor appointments.
The original rollout of RSA Security's Access Manager took six to eight months as Geisinger needed to iron out security policies that would be reasonable for an external user (internal policies may not have been applicable). The team included IT staff specializing in Web services, network infrastructure, firewalls and desktop applications, a HIPAA officer and internal auditor, among others.
Initially Geisinger would only sign up people who came to its clinic and could verify their identity with a picture ID. Today Geisinger takes registration requests online, then sends the patient an activation medical code to the address in their file. With this approach, the hospital has been able to prevent fraud and has increased the activation rate from 50 percent to 70 percent.
"[Protecting and ensuring identities] are keys to the kingdom--we're liable for that," says Young.
Managing workstation interaction
Organizations need to make architectural decisions about how SSO systems interact with the workstation.
The good news with WAM systems is the client is the Web browser, which makes WAM systems interoperable with most workstation operating systems. However, there are some differences with Windows workstations running Internet Explorer because users can access resources protected by WAM systems via their Windows credentials.
The implementation becomes more complicated when it comes to eSSO. The first major question is whether to implement the eSSO client on the user's workstation, thin client, or both. One significant benefit of using the thin client with eSSO is that it minimizes software deployment to the user's workstation. Another potential benefit is that mobile devices may be able to leverage the eSSO system. Organizations with stronger authentication goals will generally have eSSO client software on the workstation, since it may be required for user authentication.
[how it works]
Enterprise single sign-on (eSSO) solutions have client and server components that log the user on to target applications by replaying user credentials. These credentials are almost always username and password, and target applications do not need to be modified to work with the eSSO system.
The eSSO client interacts with the target application client to authenticate the user. The eSSO wallet stores usernames, passwords and other context information necessary to facilitate SSO into the application. The eSSO client leverages the credentials stored in the wallet to authenticate the user to applications as they are executed on the workstation. The wallet is typically encrypted while at rest, and then opened by the eSSO client after the user successfully authenticates to the eSSO system.
In terms of providing eSSO capabilities, vendors have two approaches: scripting and application wizards.
Scripting eSSO systems uses an interpreter to call up the target application, fill in the username and password fields, and then log the user in to the target application. The development of the scripts may not be a trivial effort due to the number of target applications, use cases (including password changes) and target application interaction complexity. In addition, scripting systems typically require modifying the user's desktop icons to call the eSSO script instead of the target application executable. As compared to application wizard eSSO systems, scripting systems may provide the additional flexibility to tackle more complex target application logins (e.g., multiple nested login or password setting dialogue boxes).
By contrast, eSSO systems that utilize application wizards typically run a service that continually monitors the workstation for login dialogue boxes. The application wizard will initially query the user to identify and populate the necessary sign-on fields for future access. When the service recognizes an application (via the executable and window names and field-control IDs, for example), it will attempt to log the user in to the application.
Some eSSO systems may even combine the two approaches. For example, a scripting eSSO system may run a login monitoring service, but use scripts to complete the login to the target application. The benefit is that the user's desktop icons do not need to be modified.
Under the Covers
With enterprise single sign-on, seven different components interact to allow the user to use one password to access target applications without re-authenticating.
Client: The client is installed on user workstation (or the user's thin client session). The client is responsible for authenticating the user to the eSSO system and managing target application logons.
Engine: The engine is a subsystem of the client. It interacts with the target applications. Engines are either script- or wizard-based.
Wallet: The user's wallet stores target application credentials. The engine replays these credentials to log the user on to the target application.
Repository: The repository stores the users' encrypted wallets, and may be either an LDAP directory or a relational database.
Authentication Service: The authentication service authenticates the user to the eSSO system, either by prompting for the password (or other stronger authenticator), or leveraging the user's authentication to the workstation.
Roaming Service: This service enables the user to use different eSSO workstations.
Auditing Service: The auditing service audits user access to target applications, but will not be able to see user logins to the target application from non-eSSO workstations.
eSSO Policy Management
Some organizations want to enable the benefits of eSSO for personal target applications like Internet banking; others don't want to deal with the potential issues of storing personal information, or have sensitive target applications that must be excluded from eSSO. To accommodate this, most eSSO systems have blacklists and whitelists that enforce which target applications are accessible via eSSO.
During the deployment phase, organizations must decide whether target application passwords should be obfuscated (that is, randomized and hidden from the user), which brings security and usability implications. Target application password obfuscation is important if stronger authentication is used since it helps prevent users (legitimate or otherwise) from bypassing the stronger authentication and accessing the target application directly. Most eSSO systems can obfuscate passwords on a per-target application basis, so that some target applications (for example, Outlook Web Access) can be accessed from home, but applications deemed more sensitive can have obfuscated passwords. Provisioning systems can assist with password obfuscation by setting the password in both the target application and the user's eSSO wallet. A few eSSO systems have a Service Provisioning Markup Language (SPML) interface, which enables interoperability without deploying a provisioning agent on the eSSO system.
Most eSSO systems also have logout policies. The system gracefully logs out of target applications upon workstation logout or a specified inactivity period. One benefit is a good audit trail of user login/logout activity, which can assist with compliance initiatives. Another benefit is not locking users out of target applications that have a single login policy (which precludes the access from two workstations at the same time).
Some target applications can be accessed offline (for example, Lotus Notes), so most eSSO systems have offline/ online policies that specify whether the user can locally authenticate without connecting to the eSSO server. Some stronger authentication mechanisms may not work well offline (though this is improving). Those eSSO systems that support offline login frequently have a wallet refresh policy, which forces users to connect to the eSSO server after a specified period of time to update their wallets.
SSO emerging solutions
Federated SSO is a solution in response to the real-world problem of users accessing Web applications across security domains. The development of federation products was initially driven by the Web access management (WAM) vendors. The current market also includes stand-alone federation products and others, including SSL VPNs, virtual directories, fine-grained authorization and XML/Web services security.
Common applications for federation include the following:
- Web SSO to benefits Web sites: Employees at a large corporation can authenticate once when accessing the employee portal and get access to external benefits Web sites (for example, retirement investment accounts).
- Intra-organization Web SSO: Due to subsidiary acquisitions and political issues within large corporations, heterogeneous Web applications are distributed across multiple security domains, but users can get Web SSO to these applications.
- B2C partnerships: Some businesses with common customers can provide "one-stop shopping" with a single authentication and personalized environment.
In the case of the travel industry (airline, hotel and car rental Web sites), the user's destination city and airport, as well as their length of stay, can be shared between the businesses to provide a seamless shopping experience.
Most federation deployments use security assertion markup language (SAML) to facilitate Web SSO. SAML assertions are XML-based documents that are typically digitally signed by the identity provider, who is responsible for the initial user authentication.
When the user arrives at the service provider's site, the service provider retrieves the user's SAML assertion, validates the identity and authentication status and enables access to the local resources without reauthentication.
Federation technologies have coalesced around the SAML 2.0 specification, which unifies the SAML 1.x standard, the Liberty Alliance Identity Federation Framework (ID-FF) specification, and others. SAML 2.0 is not backward compatible with the SAML 1.x specification, which many federation early adopters are currently using. A number of federation deployments leverage Liberty Alliance's ID FF1.2 to support user global logout.
To add to the mix, Microsoft released Active Directory Federation Services (ADFS) as part of Windows Server 2003 R2 in early 2006. ADFS does not utilize SAML 2.0, but instead uses WS-Federation. Within the enterprise, ADFS can also be utilized to facilitate cross-forest trust in a firewall-friendly manner. ADFS includes support for a SAML 1.1-based token, but not the SAML protocol.
Interoperability between WS-Federation and SAML-based environments is provided within some federation products. Many federation products can also bridge the gap between the other standards available in the marketplace and provide interoperability between WS-Federation, SAML 1.x, Liberty and SAML 2.0 federation systems.
While federation technologies do a good job of providing Web SSO, some challenges remain.
First, the negotiation of the legal federation agreements between organizations can be complicated due to liability and trust issues. Some of the difficulty with business agreements can be attributed to the industry's lack of experience with this process. But over time, these agreements will become easier. Moreover, the increase in industry marketplaces that leverage federation will help provide all implementers with more real-world examples.
While federation can facilitate user authentication, most service provider Web applications require the creation or mapping of a known user account.
Lastly, PKI permeates federation, as it is the default mechanism to establish technical trust between the identity provider and the service provider. Compared to other PKI models, federation has a simpler approach since digital certificates are not issued to users. Rather, certificates are issued to the federation components, like the identity provider and, potentially, the service provider. Organiza-tions must pay close attention to the certificates' expiration date, or risk interrupting user access to Web resources. Other challenges with PKI exist (for example, secure key storage and trust hierarchies)
Web Access Management
[how it works]
Web access management (WAM) systems provide SSO across heterogeneous Web applications and are a staple in most large enterprises. Unlike eSSO systems, WAM systems typically do not replay usernames and passwords into Web applications; they go beyond eSSO by providing authorization controls to Web resources. WAM systems do not have clients, per se, since access to resources is via the Web browser.
In most cases, the user authenticates once when accessing a resource protected by the WAM system. The WAM issues the browser a cryptographically protected cookie, which maintains authentication state across Web applications protected by the WAM system. The two principal benefits of WAM systems are Web single sign-on and externalization of Web application security. Security externalization typically results in simpler policy maintenance, since authorization and authentication are not maintained within every Web application. Security externalization can also result in improved compliance, as the organization has a holistic view of Web application security for those applications under WAM control.
WAM Policy Management
Unlike eSSO systems, WAM systems can usually enforce authorization to applications. The richer policy model comes with a price--the organization generally spends more time creating a WAM policy than an eSSO policy.
When discussing Web access management policies, it's not uncommon to hear the words "roles" and "rules." Organizations can use a combination of roles and rules to build their WAM authorization policies. The use of LDAP groups to determine access is an example of role-based authorization. Rules are used to both provide fine-grained authorization as compared to role-based access, and to limit role proliferation. With rules, an attribute, which is frequently attached to the user object in LDAP, is used in conjunction with regular expressions to determine access. One example of rule-based authorization is, "If the user's accounts payable signing limit is greater than $50,000, the user can approve the payment."
The WAM system can use both roles and rules concurrently to determine access rights. The use of rule-based authorization should be used with great care, as excessive use can complicate the debugging of authorization policy and potentially slow down the performance of the WAM system.
Agent: Agents are installed on Web servers and other resources, and are responsible for enforcing authentication and authorization. Some Web applications may have their own internal authorization that cannot be externalized, and in this case, the agent enforces only authentication. Agents can also be proxy-based, to provide authentication and authorization services to resources without a locally installed agent.
Policy Server: The agent takes its cues from the policy server, which dictates how the user should authenticate, and what resources he or she has access to. The policy server usually has a Web-based administrative interface.
Repository: The repository stores information about users and WAM policy. Typically, the repository is an LDAP directory.
Best of Both Worlds
[integrating eSSO and WAM]
It is possible to integrate WAM and eSSO systems. The benefit is SSO to both environments, with a single authentication and robust authorization capabilities for Web applications. In addition, since some WAM systems support federation, an organization can provide SSO to enterprise, Web and federated applications. Organizations can integrate eSSO and WAM via the following methods:
- Use identity management vendors' capabilities to integrate WAM and eSSO. In this case, the eSSO client will typically push its own authentication token into the Web browser as a cookie. When the user visits a Web application protected by the WAM system, the WAM system validates the eSSO authentication cookie, and then issues a WAM authentication cookie. The benefit of this approach is tighter integration of eSSO and WAM policy, and potentially easier management of the user identity.
- Extend the organization's Windows infrastructure to bind the eSSO and WAM systems together. Once the user has authenticated to Windows, he can get SSO to Microsoft Web applications. But, there are some domain trust issues, minimum Web browser requirements and non-Windows Web application issues.
- Leverage the eSSO system's Web authentication capabilities. In this scenario, the eSSO application completes the Web authentication form for the WAM system and transparently logs the user on to the WAM system. This method is generally the least secure because the password is replayed into the Web application. Other methods typically utilize some cryptography to transition the session.
In the Trenches - by Ken Tyminski
A User's Perspective
Single sign-on is about serving customers-- whether they're your employees or paying clients. As a department that provides technology services, it is important to consider the customer experience.
That's easier said than done. To be honest, IT has a hard time understanding what an end user experience is really like. As technologists, technology comes naturally to us, so it's difficult to understand the user frustration and despair.
When I was CISO at a large financial services company, we rolled out an SSO solution to 10,000 remote users a few years ago. Our field force had reached the point where they were using 15 to 25 applications, most of them in disconnected mode with different sign-on requirements. There were not many SSO solutions available that would meet our requirements. After evaluating several, we selected the v-Go Sign-On from Passlogix. It was an easy sell to the business unit CIO, as she was able to clearly see the potential of improved productivity. It was hard to measure ROI, but it was self-evident.
Creating an SSO environment turned out to be a process that needed to evolve in phases. First we started with the applications that would get us the most bang for the buck and then implemented other applications over time.
Lessons learned: Communication is critical. In users' minds, change is always more painful than the status quo. One of the smartest things we did was pre-populate their information so they couldn't wander too far astray. I would also recommend rolling out SSO in phases. Take a few applications that are meaningful and get them up and running. Don't overwhelm users with change.
In the end, we met our goal of improved customer satisfaction. Our users loved it, and we saw a dramatic reduction in the number of help desk calls for password/sign-on related issues.
Ken Tyminski is a former CISO for a large financial services organization.
How to avoid implementation snafus
[six recommendations to help a rollout go smoothly]
- Consider eSSO systems that play nice with your identity management environment. eSSO applications that interact with the existing identity management infrastructure will save time and money. For example, eSSO applications that store information in a LDAP directory can be easier to manage, particularly if the user's wallet is stored as an attribute of the user object. eSSO systems with provisioning interface enable organizations to manage the eSSO system from the provisioning system, minimizing administrative overhead throughout the user identity lifecycle.
- Test the eSSO system thoroughly. eSSO deployment horror stories are legendary; the organization kicks the eSSO system tires, but does not examine all the target applications in its environment. During deployment, several (or dozens) of applications are found to not work with the eSSO system, or require months of custom programming. Some target applications are inherently difficult for eSSO systems, particularly Java Swing applications.
- Integrate WAM and eSSO systems. If you have WAM and eSSO systems, consider integrating them. In doing so, your users get SSO to both desktop and Web applications, and potentially SSO to federated applications at your partner sites. You also get the authorization capabilities that the WAM system can deliver, which can improve overall security and compliance.
- Use stronger authentication. Stronger authentication can reduce security risks. Many vendors have integrated stronger authentication capabilities in their eSSO systems, and most WAM systems work with one-time passwords (OTP) and smart cards (via certificate). Organiza-tions must still address residual eSSO target application password risks with appropriate network security and anti-malware controls.
- Obfuscate eSSO target application passwords. Most eSSO systems can obfuscate the target application password and negotiate the password change with the target system. Provisioning system can obfuscate passwords and update both the target application and the eSSO wallet.
- Accelerate eSSO target application password aging. If the password can be obfuscated, it can be changed more frequently. While password aging policies vary, few organizations force users to change passwords more frequently than 30 days due to the associated user burden. If the organization can change the password more frequently without impacting the user, then the security of the target applications gets better.
If implemented properly, eSSO and WAM systems can improve usability and compliance. Each system has different benefits, and can be integrated to provide enhanced SSO and authorization. While preparing for an SSO project may take some planning and time, it is one of the few applications where the benefits are readily apparent to the user.
"We now have more than 50 applications supported with SSO," says Enterprise Bank & Trust's Siress. "We're really excited by our progress, and the acceptance is there." At Geisinger Health System, 60,000 patients have signed up for the Web-based service, and another 700 are signing up per week, says Young. In the meantime, Good Samaritan Hospital has significantly reduced the time to log in to various applications "Our nurses have told us, 'Don't you dare take this away,'" laughs Christian.
Now that's customer satisfaction.