Chapter 1   Introduction


This chapter provides an overview of iPlanet Web Server: Plug-in for Trustbase services

About the Identrus Scheme

---

Identrus was formed to establish and operate a highly secure system for identifying parties over electronic networks, including the Internet. Identrus is comprised of regulated financial institutions coming together to combine the basic technology provided by public key cryptography and PKI with adherence to a common set of operating rules that facilitate electronic commerce.

The "Four Corner" model, as depicted below, forms the basis of the Identrus PKI network.

Figure 1-1    Identrus Four-Corner Model

The four corners consist of:

• Issuing Participant - Bank (or other financial institution) issuing smart cards containing private keys and certificates to Subscribing Customers.

• Subscribing Customer - Member of the Issuing Participant bank authorised to participate in Identrus activities.

• Relying Customer - Party with whom the Subscribing Customer initiates a signed transaction.

• Relying Participant - Bank with which the Relying Customer communicates to obtain some level of trust in the signed data received from the Subscribing Customer.

A typical transaction using the Four-Corner Model includes the following steps:

• The Subscribing Customer uses his/her SmartCard to sign a transaction request that the system sends to the Relying Customer.

• The Relying Customer verifies that the signed data came from the Subscribing Customer and was not modified in transit.

• The Relying Customer requests services from his/her bank; for example, he/she can ask its bank to perform a status check on the Subscribing Customer's certificate to make sure it is still valid (has not been revoked).

• The Relying Participant requests services of the Issuing Participant and the Identrus Root to fulfill the Relying Customer's service request.

• Based on the response from his/her bank the Relying Customer fulfills or rejects the request from the Subscribing Customer.

In order to accommodate the Identrus Scheme, the iPlanet Web Server: Plug-in for Trustbase services utilises a host system connected to the Web Server as illustrated below:

Figure 1-2    iPlanetWeb Server and the Identrus Scheme

iPlanet's Web Server Plug-in solution

---

The iPlanet Web Server: Plug-in for Trustbase services is designed for those Developers, Users and Administrators wishing to achieve reliable messaging when sending and receiving messages. Messages gain meaning if in some way they have:

• Authentication i.e. You know who the message came from

• Integrity i.e. You know the message has not changed

• Non-repudiation i.e. The sender cannot disavow the message

If and only if there exists both a valid digital signature and a verified certificate can we say that a message be non-repudiable. Without these mechanisms in place this cannot happen, and as such, the purpose of this document is to explain the main components associated with:

• Firstly configuring a system so that appropriate trusted certificate hierarchies are in place to authenticate messages via a certificate status check.

• Secondly how developers can deploy their own applications that are Identrus enabled

The iPlanet Web Server: Plug-in for Trustbase services achieves these aims by allowing the user the ability to determine the status of each message received and also to send messages with integrity if they so wish.

Inside an Identrus SmartCard

---

Part of setting up the iPlanet Web Server: Plug-in for Trustbase services involves issuing users with a SmartCard. Every Smart Card contains certificates that has an Identrus Hierarchy that defines which users can logon to the Web Server as illustrated below.

Figure 1-3    A SmartCard illustrating its Certificate Hierarchy

If a chain of trust can be built between a specific SmartCard certificate and a trusted CA, the certificate can be trusted (by inference). In such circumstances, any user that is an Identrus member can log onto the Web Server, provided the administratorhas constructed an entry in the webserver's LDAP user database and the correct certificate hierarchy is in place.

In order to become Identrus-enabled, the following certificates are needed on the Smartcard:

• An Identrus enabled Identity Certificate that provides information about who the user is.

• An Identrus enabled Utility Certificate that provides information about what access the user is authorised to have.

• An Identrus enabled Identity Certificate Authority Certificate that issues the users identity.

• An Identrus enabled Utility Certificate Authority Certificate that issues the users utility.

• Identrus Root Certificate

The Identrus Certificate Scheme

---

Administrators wishing to install the iPlanet Web Server: Plug-in for Trustbase services need to be aware of the main components that go into enabling users to achieve these aims. The diagram below illustrates an example of how messages typically might be validated and checked for integrity using certificates that have been issued by appropriate certificate Authorities within the Identrus Scheme.

Figure 1-4    Overview of Certificate Verification for the Identrus Scheme

How iWSPTS fits in with iTTM

---

iPlanet Trustbase Transaction Manager (iTTM) processes Certificate Status checks from the Relying Participant (RP), Issuing participant (IP) and the Identrus Root (IR) They are initiated, however, by iPlanet Web Server: Plug-in for Trustbase services (iWSPTS) at the level of the Relying Customer(RC) or the Subscribing Customer (SC) as illustrated below

Figure 1-5    Initiating Certificate Status Checks

The following iPlanet products are utilised in this process

• iPlanet Web Server: Plug-in for Trustbase Services (iWSPTS)

• iPlanet Trustbase Transaction Manager (iTTM)

• iPlanet Web Server (iWS) and iPlanet Application Server (iAS)

• Certificate Management System (CMS)

iWSPTS Architecture Overview

---

The purpose of the IWS Plug-In is twofold:

• To provide a means of integrating Identrus CSC checks into merchant applications

• To provide users with a means of using the Identrus Smart Card as an authentication token

Figure 1-6    Archiectural Overview

The integration of CSC checks into merchant applications is provided as a Java API, and as such has no specific user interaction. The authentication process is as follows:

•    The user loads the URL for the application or is redirected to it from a secured URL , and is presented with an HTML page containing a notice to place the smartcard into its reader for authentication and type in their application user name.

•    The user asked to grant system access to the smart card interface applet.

•    When using the Smart Card interface, the HTML page contains a signature tag in order to activate the Smart Card plug in. This presents the user with password / PIN dialogue request and the user enters the appropriate information. The user is then presented with a random string value and asked if they wish to sign the data. The user presses accept, and the form (along with the signed data is submitted)

• If the authentication fails the user is directed to an authentication failure page containing an appropriate message, the original URL value, and a link to the smartcard authentication page.

At the highest level the architectural model has three major components that must interact for the authentication system to work. A client who is normally the subject of the request, A bank that must respond to such a request and the Service Provider or Seller that normally initates the request in the first place.