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.
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.
This was first published in August 2006