With single sign-on (SSO), users are authenticated only once, regardless of how many servers or services they attempt to access after the initial logon. Essentially, the network remembers users' logon credentials and uses them whenever users attempt to access a resource. For example, a user logs on to her workstation, then decides to access a company database. Typically, the database would require another username and password for authentication. But in an SSO environment, the application simply determines whether it can authenticate the user based on information the network's authentication server provides. SSO solves two major problems: users having to enter authentication information multiple times and users having to remember multiple sets of authentication information.
With centralized authentication, this authentication process is different. Using the example above, logging on to the database isn't transparent; the user would have to enter her authentication information again. However, the required credentials would be identical to the credentials she used to log on to her workstation. Centralized authentication effectively solves only one problem: users having to remember multiple sets of authentication credentials.
So why use centralized authentication when you can use SSO? Typically, cost and solution availability are essential factors in determining which method to use. You can configure many systems and services to authenticate users against a centralized user database (e.g., Active Directory—AD, Lightweight Directory Access Protocol—LDAP, or Network Information Service—NIS), but few of them will let you tightly integrate with the authentication framework so that you can use SSO. Even when SSO is possible, solutions can be expensive, especially in heterogeneous environments. Therefore, centralized authentication is often the best choice, even if it's only a first step toward a true SSO environment.
End of Article
Register
