Build and Implement A Single Sign-On Solution
By Chris Dunne2004-01-28
Why choose single sign-on?
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.
Tutorial pages:
|
First published by IBM developerWorks
|
|||||||||
You might also want to check these out:
|
Leave a Comment on "Build and Implement A Single Sign-On Solution"
You must be logged in to post a comment.
Link to This Tutorial Page!

