Build and Implement A Single Sign-On Solution
By Chris Dunne
2004-01-28
Reader Rating: 
Why choose single sign-on?
How many of you have had to implement your own authentication mechanism -- usually some simple database lookup? How often have you stopped to think about the workflow needed for creating and managing user accounts? This is a common task in any development project. If you are lucky, your organization already possesses some common classes or libraries you can use. But it is often a task that is overlooked -- seen as trivial, something that occurs only in the background.
In general, a coherent authentication strategy or a solid authentication framework is missing. Over time this leads to a proliferation of applications, each of which comes with their own authentication needs and user repositories. At one time or another, everyone needs to remember multiple usernames and passwords to access different applications on a network. This poses a huge cost for the administration and support departments -- accounts must be set up in each application for each employee, users forget their passwords, and so on.
Authentication is a horizontal requirement across multiple applications, platforms, and infrastructures. In general, there's no reason why user Mary should need multiple usernames. Ideally she should only need to identify herself once and then be provided with access to all authorized network resources.
The objective of SSO is to allow users access to all applications from one logon. It provides a unified mechanism to manage the authentication of users and implement business rules determining user access to applications and data.
Before I get into the technical details of single sign-on, take a quick look at some of the benefits and some of the risks. Benefits include the following:
• Improved user productivity. Users are no longer bogged down by multiple logins and they are not required to remember multiple IDs and passwords. Also, support personnel answer fewer requests to reset forgotten passwords.
• Improved developer productivity. SSO provides developers with a common authentication framework. In fact, if the SSO mechanism is independent, then developers don't have to worry about authentication at all. They can assume that once a request for an application is accompanied by a username, then authentication has already taken place.
• Simplified administration. When applications participate in a single sign-on protocol, the administration burden of managing user accounts is simplified. The degree of simplification depends on the applications since SSO only deals with authentication. So, applications may still require user-specific attributes (such as access privileges) to be set up.
Some of the more frequently mentioned problems with single sign-on include the following:
• Difficult to retrofit. An SSO solution can be difficult, time-consuming, and expensive to retrofit to existing applications.
• Unattended desktop. Implementing SSO reduces some security risks, but increases others. For example, a malicious user could gain access to a user's resources if the user walks away from his machine and leaves it logged in. Although this is a problem with security in general, it is worse with SSO because all authorized resources are compromised. At least with multiple logons, the user may only be logged into one system at the time and so only one resource is compromised.
• Single point of attack. With single sign-on, a single, central authentication service is used by all applications. This is an attractive target for hackers who may decide to carry out a denial of service attack.
So, SSO is not without its disadvantages, but I believe the advantages from a viewpoint of users, administrators, and developers can outweigh those disadvantages.
First published by IBM developerWorks
If you found this article interesting, you may want to read these as well:
» Scheduling Recurring Tasks In Java Applications
» Eye On Performance: A Load Of Stress
» A Brief History Of Garbage Collection
|
