This article can also be found in the Premium Editorial Download "Information Security magazine: Special manager's guide: Monitoring identities."
Download it now to read this article plus other related content.
|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.
This was first published in August 2006