Features to Look For
When researching single sign-on products for your enterprise, here are some features that you'll want to look for, and ask the vendors about.

7 URL Mapping hides URLs that you are not suppose to have access to.

7 Personalization provides customized user specified features.

7 Smart Card supports allows authentication via smart cards.

7 Transparent Implementation means that client-side software is not required.

7 Encryption algorithms offer advanced security. Ask which ones are supported.

7 Digital IDs or Signatures mean that electronic signing capabilities exist.

7 Client Platforms indicate which user operating systems can authenticate.

7 Central Management indicates administration of many servers from one console.

7 Cross-Domain Authentication lets you authenticate multiple domain architectures.

7 X.509 allows for support of digital certificates.

7 Logging indicates the type of account auditing features available for review.

The importance of these features to your organization depends on how you want to use your single sign-on platform today, and how you might want to use your single sign-on platform down the road, perhaps a year from now. For example if you have both UNIX and NT domains, cross-domain authentication will be of paramount importance. If you are not going to be using your single sign-on solution for a customer, supply-chain, or partner portal, than personalization might have little, if any, importance.

A feature that is particularly important for just about all large-scale implementations is the ease-of-use of the central management console. If you are supporting a vast array of applications, the central management console is what brings the administration altogether. The administrator should be sure to understand what sort of process is required to update or change a rule or role. Does this change take place instantaneously? A very good test on determining administrator ease-of-use would be to test out adding, deleting, and changing a user's role on each product in consideration. Also, how hard or easy is it to setup rules?

Next, ask about the logging features. Can the logs be filtered on various criteria? You might want to find out for example, which IP addresses are continually trying to get in, but are not being allowed access. This could be useful to know in case you have a computer breach down the road, maybe from some other part of your network that is not connected to the single sign-on infrastructure. Things that you will want the log files to filter on will be domains, IP addresses, or even user names. Of course if these filters don't exist, you can resort to writing your own filters using grep and awk shell-scripts. Don't forget to ask if the log files roll-over and archive so you don't have to worry about your file systems filling up.

Installing and administering most single sign-on products on UNIX platforms don't require much advanced knowledge of UNIX itself. Most of the products are GUI driven, and their installation, configuration, and management are based on point, click, and return-key sequences. The part of the implementation that takes some understanding is assigning the rules and the roles.

Single Sign-on is Worth the Effort
There are clearly benefits to be gained from implementing single sign-on systems. Though people equate the terminology "single sign-on" to security, what you are really getting with these implementations are much more than that. If you're looking to reduce your support calls and expenses, and simplify the authentication process for your users, single sign-on systems offer clear benefits to your organizations. The ability to reduce operational costs, create an improved user experience, and provide advanced security to your systems makes single sign-on well worth the effort.