| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
5.5.2 Single Sign-on Network Operating Systems were designed to behave independently of other systems. For example, in the Windows world, if a user wanted a resource in a domain that was different than the domain they are held in, the administrator had to tell the second domain to be trusting of the fact that the first domain provided proper security, so that the user did not have to have separate sets of user IDs and passwords, one per domain. The alternative was to have that user also have user and group membership on the second domain, this increased administration overhead. The situation grows more complex when todays multi-vendor networks and complex applications are taken into account. A user might require access to the organizations UNIX machine, NT file servers, and several database applications. Maintaining different accounts for the user on each platform is a headache for network administrators, and keeping track of an entire handful of user ID/password combinations a headache for users. With Single Sign-on, instead of using a password to verify a user when accessing data protected by an Access Control List (ACL), the clients identity is often verified using a certificate. The idea behind single sign-on is to require the client to authenticate just once (presenting credentials like a smart card or even a user ID and password, if certificates are not used), and have this identity automatically relayed to each server/application the client accesses, when authorization is required, without the user having to perform extra steps.
Home - Table Of Contents - Contact Us CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com Version 1.0 - Version Date: November 15, 2004 Adapted with permission from a work created by Tcat Houser et al. CertiGuide.com Version © Copyright 2004 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |