Sunday, January 4, 2009
Planning and Deploying a Single Sign-On Solution
Intranet users are commonly required to use a separate password to authenticate themselves to each server they need to access in the course of their work. Multiple passwords are an ongoing headache for both users and system administrators. Users have difficulty keeping track of different passwords, tend to choose poor ones, and tend to write them down in obvious places. Administrators must keep track of a separate password database on each server and deal with potential security problems related to the fact that passwords are sent over the network routinely and frequently.
Solving this problem requires some way for a user to log in once, using a single password, and get authenticated access to all servers that user is authorized to use--without sending any passwords over the network. This capability is known as single sign-on.
Netscape supports single sign-on for Navigator 3.x, Communicator, Communicator Professional Edition, and most of the SuiteSpot 3.x servers. Netscape's approach to single sign-on involves the use of digital certificates to authenticate users to servers. For Netscape products, single sign-on is an authentication mechanism that replaces more cumbersome multiple-password authentication without affecting existing access-control mechanisms.
This document introduces single sign-on for network administrators and describes how to plan and deploy a single sign-on solution using Netscape products.
* Introduction to Single Sign-On
* Planning a Single Sign-On Solution
* Setting Up Netscape Servers for Single Sign-On
* Setting Up Netscape Clients for Single Sign-On
* Issuing Client Certificates
* Testing Your Setup Before Full Deployment
This document assumes that you are familiar with basic concepts of public-key cryptography, including public and private keys, certificates, and digital signatures. For a brief introduction, see Appendix A, "Netscape's Use of Public-Key Cryptography."
To give Netscape comments on this guide or on any aspect of single sign-on, please send email to sso-feedback. This address is strictly for collecting feedback; you will not receive a personal response.
For information about getting technical help with any Netscape product, see Netscape Tech Support.
Solving this problem requires some way for a user to log in once, using a single password, and get authenticated access to all servers that user is authorized to use--without sending any passwords over the network. This capability is known as single sign-on.
Netscape supports single sign-on for Navigator 3.x, Communicator, Communicator Professional Edition, and most of the SuiteSpot 3.x servers. Netscape's approach to single sign-on involves the use of digital certificates to authenticate users to servers. For Netscape products, single sign-on is an authentication mechanism that replaces more cumbersome multiple-password authentication without affecting existing access-control mechanisms.
This document introduces single sign-on for network administrators and describes how to plan and deploy a single sign-on solution using Netscape products.
* Introduction to Single Sign-On
* Planning a Single Sign-On Solution
* Setting Up Netscape Servers for Single Sign-On
* Setting Up Netscape Clients for Single Sign-On
* Issuing Client Certificates
* Testing Your Setup Before Full Deployment
This document assumes that you are familiar with basic concepts of public-key cryptography, including public and private keys, certificates, and digital signatures. For a brief introduction, see Appendix A, "Netscape's Use of Public-Key Cryptography."
To give Netscape comments on this guide or on any aspect of single sign-on, please send email to sso-feedback. This address is strictly for collecting feedback; you will not receive a personal response.
For information about getting technical help with any Netscape product, see Netscape Tech Support.
This approach has several benefits for users and administrators:
* Ease of use. Users can log in once and get authenticated access to all servers for which that user is authorized, without being interrupted by repeated requests for passwords.
* Password limited to local machine. To log in, the user types a single password that protects the private-key database on the local machine. Passwords are not sent over the network.
* Simplified management. Administrators can control who is allowed access to which servers by controlling the lists of certificate authorities maintained by client and server software. These lists are shorter than lists of user names and passwords and don't change as often.
* Access control not affected. Single sign-on involves replacing client authentication mechanisms, not access-control mechanisms. Administrators don't need to change existing ACLs that may have been originally set up to work with basic password authentication.
Client authentication based on name and password is often called basic authentication. There are several ways of simplifying basic authentication, for example by requiring users to use the same password for different servers or by keeping track of passwords automatically. Although Netscape products support such approaches, these are not true single sign-on as described in this document. Netscape's single sign-on solution requires the use of certificate-based authentication, sometimes called strong authentication.
A certificate is an electronic document used to identify an individual, company, or other entity. Certificate authorities (CAs) are entities that validate identities and issue certificates. CAs are either independent third parties or organizations running their own certificate-issuing server software (such as Netscape Certificate Server). For more information about certificates and public-key cryptography, see Appendix A, "Netscape's Use of Public-Key Cryptography."
The following sections introduce the use of single sign-on with Netscape products:
* Client Authentication and Single Sign-On
* Netscape Products That Support Single Sign-On
Client Authentication and Single Sign-On
Information sent from one computer to another over a TCP/IP network can pass through numerous other computers before it reaches its destination, making it theoretically possible to eavesdrop or even replace information along the way. In addition, users don't have any assurance that a web site they visit is what it purports to be, and server administrators don't know which users visit their web sites.
Although such security risks don't matter for most casual uses of the Internet, they are not acceptable within an enterprise intranet or extranet. Administrators can address some of these risks by using client and server software that provides some form of authentication. For example, if you must type your name and password before accessing a server, the server uses that information and an internal database to authenticate your identity--to confirm that you are who you say you are.
Authentication by itself, however, doesn't address threats to privacy or data integrity. The Secure Sockets Layer (SSL) standard supported by Netscape products addresses the need for authentication, privacy, and data integrity. SSL is a protocol that runs above TCP/IP and below HTTP, LDAP, IMAP, NNTP, and other high-level network protocols. SSL allows an SSL-enabled server to authenticate itself to an SSL-enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection.
A server-authenticated SSL connection makes it extremely difficult to eavesdrop on the connection, modify the data without detection, or impersonate the identity of the server. However, unless the client as well as the server is authenticated, any user can establish a connection and gain access to the resources managed by the server.
Client authentication is an essential element of network security within most intranets or extranets. The sections that follow contrast the two forms of client authentication introduced in Figure 1:
* Basic Authentication. Almost all server software permits client authentication by means of a name and password. This form of authentication may take place in the clear (that is, without encryption) or over a server-authenticated and encrypted SSL connection.
* Strong Authentication. Client authentication based on certificates, as implemented by Netscape, requires SSL. This is the form of authentication used to support single sign-on for Netscape products.
This guide does not discuss the step-by-step details of the SSL handshake and server and client authentication mechanisms. For more information about SSL, see Chapter 4, "Understanding Encryption and SSL," in Managing Netscape Servers.
Basic Authentication
Figure 2 shows the basic steps involved in authenticating a client by means of a name and password. Note that the figure doesn't take into account the details of the underlying SSL connection, if there is one. In the figure, the following is assumed:
* The user has already decided to trust the server, either without authentication or on the basis of server authentication via SSL.
* The user has requested a resource.
* The server has requested client authentication in the process of evaluating its access-control lists (ACLs) for the requested resource.
Figure 2 Using a password to authenticate a client to a server
hese are the steps shown in Figure 2:
1. In response to an authentication request from the server, the client displays a dialog box requesting the user's name and password for that server. The user must supply a name and password separately for each new server the user wishes to use during a work session.
2. The client sends the name and password across the network, either in the clear or over an encrypted SSL connection.
3. The server looks up the name and password in its local password database and, if they match, accepts them as evidence authenticating the user's identity.
4. The server continues evaluating its ACLs (optionally making use of information stored in the LDAP directory, in company databases, and so on), determines whether the identified user is permitted to access the requested resource, and if so allows the client to access it.
With this arrangement, the user must supply a new password for each server, and the administrator must keep track of the name and password for each user, typically on separate servers.
As shown in the next section, single sign-on replaces the first three steps with a mechanism that allows the user to supply just one password (which is not sent across the network) and allows the administrator to control user authentication centrally with the aid of the Certificate Server and the Directory Server.
Strong Authentication
Netscape's approach to single sign-on uses a single certificate rather than multiple passwords to authenticate a client to multiple servers. A certificate identifies an individual, a server, or some other entity. To authenticate a user to a server, a client digitally signs a randomly generated piece of data and sends both the certificate and the signed data across the network, as shown in Figure 3. For the purposes of this discussion, the digital signature associated with some data can be thought of as evidence provided by the client to the server. The server authenticates the user's identity on the strength of this evidence.
As in Figure 2, in Figure 3 it is assumed that the user has already decided to trust the server and has requested a resource, and that the server has requested client authentication in the process of evaluating its access control lists (ACLs) for the requested resource.
Figure 3 Using a certificate to authenticate a client to a server
Unlike the process shown in Figure 2, the process shown in Figure 3 requires the use of SSL and takes place after the initial server authentication. It is also assumed that the client has a valid certificate that can be used to identify the client to the server. This process is called "strong authentication" because it is based on what the user has (the certificate) as well as what the user knows (the password that protects the private key).
These are the steps shown in Figure 3:
1. The client software, in this case Communicator or Navigator 3.x, maintains a database of the private keys that correspond to the public keys published in any certificates issued for that client. The client asks for the password to this database the first time the client needs to access it during a given session, for example the first time the user attempts to access an SSL-enabled server that requires certificate-based client authentication. After entering this password once, the user doesn't need to enter it again for the rest of the session, even when accessing other SSL-enabled servers.
2. The client unlocks the private-key database, retrieves the private key for the user's certificate, and uses that private key to digitally sign some data that has been randomly generated for this purpose on the basis of input from both the client and the server. This data and the digital signature constitute "evidence" of the private key's validity. The digital signature can be created only with that private key and can be validated with the corresponding public key against the data that was signed, which is unique to the SSL session.
3. The client sends both the user's certificate and the evidence (the randomly generated piece of data that has been digitally signed) across the network.
4. The server uses the certificate and the evidence to authenticate the user's identity. (For a detailed discussion of the way this works, see Appendix A, "Netscape's Use of Public-Key Cryptography.")
5. The server maps the user's identity to a unique entry in the LDAP directory and checks that the entry contains the same certificate that was presented to the server. This step assumes that the Certificate Server has been configured to publish each certificate it issues in the directory. To disallow authentication for a particular user, (for example, someone who has left the company), the administrator simply removes the person's certificate from the LDAP directory. This single action prevents that person from accessing any of the company's servers, even if the person's certificate hasn't expired.
6. If the LDAP lookup is successful, the server continues evaluating its ACLs (optionally making use of information stored in the LDAP directory, in company databases, and so on), determines whether the identified user is permitted to access the requested resource, and if so allows the client to access it.
As you can see by comparing Figure 3 to Figure 2, the use of certificates in single sign-on replaces the authentication portion of the interaction between the client and the server. Instead of requiring a user to enter multiple passwords throughout the day, single sign-on requires the user to enter the private-key database password just once. For the rest of the session, the client presents the user's certificate to authenticate the user to each new server it encounters. Existing access-control mechanisms based on the authenticated user identity are not affected.
http://docs.sun.com/source/816-6151-10/sso.htm
Solving this problem requires some way for a user to log in once, using a single password, and get authenticated access to all servers that user is authorized to use--without sending any passwords over the network. This capability is known as single sign-on.
Netscape supports single sign-on for Navigator 3.x, Communicator, Communicator Professional Edition, and most of the SuiteSpot 3.x servers. Netscape's approach to single sign-on involves the use of digital certificates to authenticate users to servers. For Netscape products, single sign-on is an authentication mechanism that replaces more cumbersome multiple-password authentication without affecting existing access-control mechanisms.
This document introduces single sign-on for network administrators and describes how to plan and deploy a single sign-on solution using Netscape products.
* Introduction to Single Sign-On
* Planning a Single Sign-On Solution
* Setting Up Netscape Servers for Single Sign-On
* Setting Up Netscape Clients for Single Sign-On
* Issuing Client Certificates
* Testing Your Setup Before Full Deployment
This document assumes that you are familiar with basic concepts of public-key cryptography, including public and private keys, certificates, and digital signatures. For a brief introduction, see Appendix A, "Netscape's Use of Public-Key Cryptography."
To give Netscape comments on this guide or on any aspect of single sign-on, please send email to sso-feedback. This address is strictly for collecting feedback; you will not receive a personal response.
For information about getting technical help with any Netscape product, see Netscape Tech Support.
Solving this problem requires some way for a user to log in once, using a single password, and get authenticated access to all servers that user is authorized to use--without sending any passwords over the network. This capability is known as single sign-on.
Netscape supports single sign-on for Navigator 3.x, Communicator, Communicator Professional Edition, and most of the SuiteSpot 3.x servers. Netscape's approach to single sign-on involves the use of digital certificates to authenticate users to servers. For Netscape products, single sign-on is an authentication mechanism that replaces more cumbersome multiple-password authentication without affecting existing access-control mechanisms.
This document introduces single sign-on for network administrators and describes how to plan and deploy a single sign-on solution using Netscape products.
* Introduction to Single Sign-On
* Planning a Single Sign-On Solution
* Setting Up Netscape Servers for Single Sign-On
* Setting Up Netscape Clients for Single Sign-On
* Issuing Client Certificates
* Testing Your Setup Before Full Deployment
This document assumes that you are familiar with basic concepts of public-key cryptography, including public and private keys, certificates, and digital signatures. For a brief introduction, see Appendix A, "Netscape's Use of Public-Key Cryptography."
To give Netscape comments on this guide or on any aspect of single sign-on, please send email to sso-feedback. This address is strictly for collecting feedback; you will not receive a personal response.
For information about getting technical help with any Netscape product, see Netscape Tech Support.
This approach has several benefits for users and administrators:
* Ease of use. Users can log in once and get authenticated access to all servers for which that user is authorized, without being interrupted by repeated requests for passwords.
* Password limited to local machine. To log in, the user types a single password that protects the private-key database on the local machine. Passwords are not sent over the network.
* Simplified management. Administrators can control who is allowed access to which servers by controlling the lists of certificate authorities maintained by client and server software. These lists are shorter than lists of user names and passwords and don't change as often.
* Access control not affected. Single sign-on involves replacing client authentication mechanisms, not access-control mechanisms. Administrators don't need to change existing ACLs that may have been originally set up to work with basic password authentication.
Client authentication based on name and password is often called basic authentication. There are several ways of simplifying basic authentication, for example by requiring users to use the same password for different servers or by keeping track of passwords automatically. Although Netscape products support such approaches, these are not true single sign-on as described in this document. Netscape's single sign-on solution requires the use of certificate-based authentication, sometimes called strong authentication.
A certificate is an electronic document used to identify an individual, company, or other entity. Certificate authorities (CAs) are entities that validate identities and issue certificates. CAs are either independent third parties or organizations running their own certificate-issuing server software (such as Netscape Certificate Server). For more information about certificates and public-key cryptography, see Appendix A, "Netscape's Use of Public-Key Cryptography."
The following sections introduce the use of single sign-on with Netscape products:
* Client Authentication and Single Sign-On
* Netscape Products That Support Single Sign-On
Client Authentication and Single Sign-On
Information sent from one computer to another over a TCP/IP network can pass through numerous other computers before it reaches its destination, making it theoretically possible to eavesdrop or even replace information along the way. In addition, users don't have any assurance that a web site they visit is what it purports to be, and server administrators don't know which users visit their web sites.
Although such security risks don't matter for most casual uses of the Internet, they are not acceptable within an enterprise intranet or extranet. Administrators can address some of these risks by using client and server software that provides some form of authentication. For example, if you must type your name and password before accessing a server, the server uses that information and an internal database to authenticate your identity--to confirm that you are who you say you are.
Authentication by itself, however, doesn't address threats to privacy or data integrity. The Secure Sockets Layer (SSL) standard supported by Netscape products addresses the need for authentication, privacy, and data integrity. SSL is a protocol that runs above TCP/IP and below HTTP, LDAP, IMAP, NNTP, and other high-level network protocols. SSL allows an SSL-enabled server to authenticate itself to an SSL-enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection.
A server-authenticated SSL connection makes it extremely difficult to eavesdrop on the connection, modify the data without detection, or impersonate the identity of the server. However, unless the client as well as the server is authenticated, any user can establish a connection and gain access to the resources managed by the server.
Client authentication is an essential element of network security within most intranets or extranets. The sections that follow contrast the two forms of client authentication introduced in Figure 1:
* Basic Authentication. Almost all server software permits client authentication by means of a name and password. This form of authentication may take place in the clear (that is, without encryption) or over a server-authenticated and encrypted SSL connection.
* Strong Authentication. Client authentication based on certificates, as implemented by Netscape, requires SSL. This is the form of authentication used to support single sign-on for Netscape products.
This guide does not discuss the step-by-step details of the SSL handshake and server and client authentication mechanisms. For more information about SSL, see Chapter 4, "Understanding Encryption and SSL," in Managing Netscape Servers.
Basic Authentication
Figure 2 shows the basic steps involved in authenticating a client by means of a name and password. Note that the figure doesn't take into account the details of the underlying SSL connection, if there is one. In the figure, the following is assumed:
* The user has already decided to trust the server, either without authentication or on the basis of server authentication via SSL.
* The user has requested a resource.
* The server has requested client authentication in the process of evaluating its access-control lists (ACLs) for the requested resource.
Figure 2 Using a password to authenticate a client to a server
hese are the steps shown in Figure 2:
1. In response to an authentication request from the server, the client displays a dialog box requesting the user's name and password for that server. The user must supply a name and password separately for each new server the user wishes to use during a work session.
2. The client sends the name and password across the network, either in the clear or over an encrypted SSL connection.
3. The server looks up the name and password in its local password database and, if they match, accepts them as evidence authenticating the user's identity.
4. The server continues evaluating its ACLs (optionally making use of information stored in the LDAP directory, in company databases, and so on), determines whether the identified user is permitted to access the requested resource, and if so allows the client to access it.
With this arrangement, the user must supply a new password for each server, and the administrator must keep track of the name and password for each user, typically on separate servers.
As shown in the next section, single sign-on replaces the first three steps with a mechanism that allows the user to supply just one password (which is not sent across the network) and allows the administrator to control user authentication centrally with the aid of the Certificate Server and the Directory Server.
Strong Authentication
Netscape's approach to single sign-on uses a single certificate rather than multiple passwords to authenticate a client to multiple servers. A certificate identifies an individual, a server, or some other entity. To authenticate a user to a server, a client digitally signs a randomly generated piece of data and sends both the certificate and the signed data across the network, as shown in Figure 3. For the purposes of this discussion, the digital signature associated with some data can be thought of as evidence provided by the client to the server. The server authenticates the user's identity on the strength of this evidence.
As in Figure 2, in Figure 3 it is assumed that the user has already decided to trust the server and has requested a resource, and that the server has requested client authentication in the process of evaluating its access control lists (ACLs) for the requested resource.
Figure 3 Using a certificate to authenticate a client to a server
Unlike the process shown in Figure 2, the process shown in Figure 3 requires the use of SSL and takes place after the initial server authentication. It is also assumed that the client has a valid certificate that can be used to identify the client to the server. This process is called "strong authentication" because it is based on what the user has (the certificate) as well as what the user knows (the password that protects the private key).
These are the steps shown in Figure 3:
1. The client software, in this case Communicator or Navigator 3.x, maintains a database of the private keys that correspond to the public keys published in any certificates issued for that client. The client asks for the password to this database the first time the client needs to access it during a given session, for example the first time the user attempts to access an SSL-enabled server that requires certificate-based client authentication. After entering this password once, the user doesn't need to enter it again for the rest of the session, even when accessing other SSL-enabled servers.
2. The client unlocks the private-key database, retrieves the private key for the user's certificate, and uses that private key to digitally sign some data that has been randomly generated for this purpose on the basis of input from both the client and the server. This data and the digital signature constitute "evidence" of the private key's validity. The digital signature can be created only with that private key and can be validated with the corresponding public key against the data that was signed, which is unique to the SSL session.
3. The client sends both the user's certificate and the evidence (the randomly generated piece of data that has been digitally signed) across the network.
4. The server uses the certificate and the evidence to authenticate the user's identity. (For a detailed discussion of the way this works, see Appendix A, "Netscape's Use of Public-Key Cryptography.")
5. The server maps the user's identity to a unique entry in the LDAP directory and checks that the entry contains the same certificate that was presented to the server. This step assumes that the Certificate Server has been configured to publish each certificate it issues in the directory. To disallow authentication for a particular user, (for example, someone who has left the company), the administrator simply removes the person's certificate from the LDAP directory. This single action prevents that person from accessing any of the company's servers, even if the person's certificate hasn't expired.
6. If the LDAP lookup is successful, the server continues evaluating its ACLs (optionally making use of information stored in the LDAP directory, in company databases, and so on), determines whether the identified user is permitted to access the requested resource, and if so allows the client to access it.
As you can see by comparing Figure 3 to Figure 2, the use of certificates in single sign-on replaces the authentication portion of the interaction between the client and the server. Instead of requiring a user to enter multiple passwords throughout the day, single sign-on requires the user to enter the private-key database password just once. For the rest of the session, the client presents the user's certificate to authenticate the user to each new server it encounters. Existing access-control mechanisms based on the authenticated user identity are not affected.
http://docs.sun.com/source/816-6151-10/sso.htm
# posted by CHANDU @ 11:40 PM 
Subscribe to Comments [Atom]
