Scenario: Use certificates for external authentication
In this scenario, you lean when and how to use certificates as an authentication mechanism to protect and limit access by public users to public or extranet resources and applications.
Situation:
You work for the MyCo, Inc insurance company and are responsible for maintaining different applications on your company's intranet and extranet sites. One particular application for which you are responsible is a rate-calculating application that allows hundreds of independent agents to generate quotes for their clients. Because the information that this application provides is somewhat sensitive, you want to make sure that only registered agents can use it. Further, you want to eventually provide a more secure method of user authentication to the application than your current user name and password method. You are concerned additionally that unauthorized users might capture this information when it is transmitted over an untrusted network. Also, you have concerns that different agents might share this information with each other without authorization to do so.
After some research, you decide that using digital certificates can provide you with the security that you need to protect the sensitive information entered into and retrieved from this application. The use of certificates allows you to use Secure Sockets Layer (SSL) to protect the transmission of the rate data. Although eventually you want all agents to use a certificate to access the application, you know that your company and your agents may need some time before this goal can be achieved. In addition to the use of certificate client authentication, you plan to continue the current use of user name and password authentication because SSL protects the privacy of this sensitive data in transmission.
Based on the type of application and its users and your future goal of certificate authentication for all users, you decide to use a public certificate from a well known Certificate Authority (CA) to configure SSL for your application.
Scenario advantages
- Using digital certificates to configure SSL access to your rate calculation application ensures that the information transmitted between the server and client is protected and private.
- Using digital certificates whenever possible for client authentication provides a more secure method of identifying authorized users. Even where the use of digital certificates is not possible, client authentication by means of user name and password authentication is protected and kept private by the SSL session, making the exchange of such sensitive data more secure.
- Using public digital certificates to authenticate users to your
applications and data in the manner that this scenario describes is a practical
choice under these or similar conditions:
- Your data and applications require varying degrees of security.
- There is a high rate of turnover among your trusted users.
- You provide public access to applications and data, such as an Internet Web site, or an extranet application.
- You do not want to operate your own Certificate Authority (CA) based on administrative reasons, such as a large number of outside users who access your applications and resources.
- Using a public certificate to configure the rate calculating application for SSL in this scenario decreases the amount of configuration that users must perform to access the application securely. Most client software contains CA certificates for most well-known CAs.
Objectives
In this scenario, MyCo, Inc. wants to use digital certificates to protect the rate calculating information that their application provides to authorized public users. The company also wants a more secure method of authenticating those users who are allowed to access this application when possible.
- Company public rate calculating application must use SSL to protect the privacy of the data that it provides to users and receives from users.
- SSL configuration must be accomplished with public certificates from a well-known public Internet Certificate Authority (CA).
- Authorized users must provide a valid user name and password to access the application in SSL mode. Eventually, authorized users must be able to use one of two methods of secure authentication to be granted access to the application. Agents must present either a public digital certificate from a well-known Certificate Authority (CA) or a valid user name and password if a certificate is unavailable.
Details
The following figure illustrates the network configuration in this scenario:
The figure illustrates the following information about the situation for this scenario:
- iSeries™ A is the server that hosts the company's rate calculating application.
- iSeries A runs i5/OS™ Version 5 Release 4 (V5R4).
- iSeries A has Digital Certificate Manager (i5/OS option 34) and IBM® HTTP Server for i5/OS (5722–DG1) installed and configured.
- iSeries A runs the rate
calculating application, which is configured such that it:
- Requires SSL mode.
- Uses a public certificate from a well-known Certificate Authority (CA) to authenticate itself to initialize an SSL session.
- Requires user authentication by user name and password.
- iSeries A presents its certificate to initiate an SSL session when Clients B and C access the rate calculating application.
- After initializing the SSL session, iSeries A requests that Clients B and C provide a valid user name and password before allowing access to the rate calculating application.
- Clients B and C are independent agents who access the rate calculating application.
- Clients B and C client software has an installed copy of the well-known CA certificate that issued the application certificate.
- Clients B and C access the rate calculating application on iSeries A, which presents its certificate to their client software to authenticate its identity and initiate an SSL session.
- Client software on Clients B and C is configured to accept the certificate from iSeries A for the purpose of initializing an SSL session.
- After the SSL session begins, Clients B and C must provide a valid user name and password before iSeries A grants access to the application.
Prerequisites and assumptions
This scenario depends on the following prerequisites and assumptions:
- The rate calculating application on iSeries A is a generic application that can be configured to use SSL. Most applications, including many iSeries applications, provide SSL support. SSL configuration steps vary widely among applications. Consequently, this scenario does not provide specific instructions for configuring the rate calculating application to use SSL. This scenario provides instructions for configuring and managing the certificates that are necessary for any application to use SSL.
- The rate calculating application may provide the capability of requiring certificates for client authentication. This scenario provides instructions for how to use Digital Certificate Manager (DCM) to configure certificate trust for those applications that provide this support. Because the configuration steps for client authentication vary widely among applications, this scenario does not provide specific instructions for configuring certificate client authentication for the rate calculating application.
- iSeries A meets the requirements for installing and using Digital Certificate Manager (DCM)
- No one has previously configured or used DCM on iSeries A.
- Whoever uses DCM to perform the tasks in this scenario must have *SECADM and *ALLOBJ special authorities for their user profile.
- iSeries A does not have an IBM Cryptographic Coprocessor installed.