A Comprehensive Guide to IBM WebSphere Host Publisher Version 3.5

670 IBM WebSphere Host Publisher Version 3.5

Permit the DCAS to use certificate services

SETROPTS CLASSACT (DIGTCERT DIGTRING)

RDEFINE FACILITY (IRR.DIGTCERT.LIST) UACC(NONE)

RDEFINE FACILITY (IRR.DIGTCERT.LISTRING) UACC(NONE)

PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY ID(DCAS) ACCESS(CONTROL)

PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY ID(DCAS) ACCESS(CONTROL)

SETROPTS RACLIST(DIGTRING DIGTCERT) REFRESH

Define the PassTicket data profile

SETROPTS CLASSACT(PTKTDATA)

SETROPTS RACLIST(PTKTDATA)

RDEFINE PTKTDATA TSORA03 SSIGNON(KEYMASKED(E6C9D30195D4C1E7)) UACC(NONE)

SETROPTS RACLIST(PTKTDATA) REFRESH

Define the client’s certificate in RACF

RACDCERT ID(JUANR) ADD('JUANR.CERT.DER') TRUST WITHLABEL('CLIENT FOR DCAS')

SETROPTS RACLIST(DIGTRING DIGTCERT) REFRESH

21.6 Certificates

In this section, we include information about required X.509 certificates when

using the Express Logon Feature (ELF) in Host Publisher. We also illustrate how

these certificates are processed by the different components in an ELF

environment.

Client certificates

All users using ELF must have a signed client certificate. It is also understood

that the associated signer certificate or root certificate must also be available for

proper authentication.

Note: Although using self-signed certificates is not a recommended procedure,

you will also need to provide the proper root certificates in this case.

Chapter 21. Express Logon Feature (ELF) 671

Figure 21-3 Client (Web browser) certificate process in ELF

The client certificate process is illustrated in Figure 21-3 as follows:

1. A client obtains a X.509 certificate signed by a Certificate Authority (CA). The

certificate is made available to the Web browser. Again, signer certificates

must also be available.

2. The same client certificate is transferred (binary) to the S/390 and made

available using RACF commands.

3. When the HTTPS connection is established between Web browser and Web

server, the browser sends its certificate to the Web server for proper client

authentication.

4. When Host Publisher detects that an ELF has been configured for a

connection, it obtains the client (Web browser) certificate from the Web server

using the plug-in interface.

5. After the secure SSL connection has been established between DCAR and

DCAS, Host Publisher sends the client (Web browser) certificate to DCAS as

data.

Note: The application ID taken from the ELF macro is also passed to DCAS.

672 IBM WebSphere Host Publisher Version 3.5

6. DCAS receives the client (Web browser) certificate from DCAR and looks for

a match with previously defined client certificates. When a match is found and

the user is authorized to access the requested application, DCAS creates a

PassTicket using the information associated to the client certificate and other

values (user ID, application name and key, time and date information, and so

on). The PassTicket is then passed to Host Publisher to establish the Telnet

3270 connection with the TN3270 server by executing the ELF macro with the

received PassTicket.

Web server certificate

The Web server certificate is used to establish the secure HTTPS session

between clients (Web browsers) and the Web server. For ELF, the Web server

must be configured for SSL with client authentication and it will typically use the

default port number 443 for the secure session.

Figure 21-4 Web server certificate process

The Web server certificate process is illustrated in Figure 21-4 as follows:

1. The Web server obtains a X.509 certificate signed by a Certificate Authority

(CA). The certificate is made available to the Web server, for example using

the IKEYMAN tool in IBM HTTP Server. Again, signer certificates must also

be available.

Chapter 21. Express Logon Feature (ELF) 673

2. When the SSL sessions are established, the Web server sends its certificate

to the clients (Web browsers) for server authentication. Web browsers must

also have the Web server signer certificate available.

DCAR certificate

The DCAR certificate is required and used to establish the secure HTTPS

session between DCAR and DCAS. The SSL connection with DCAS requires

client authentication (mandatory) and it will typically use the default port number

8990 for the secure session.

Figure 21-5 DCAR certificates process

The DCAR certificate process is illustrated in Figure 21-5 as follows:

1. A DCAR X.509 certificate signed by a Certificate Authority (CA) is created.

The certificate is then made available to DCAR using the provided tool

IKEYMAN. See Section 21.9, “Creating a DCAR certificate” on page 681 for

details. Again, signer certificates must also be available.

2. If using level 2 or level 3 authentication, you must also use binary transfer and

define the DCAR certificate using RACF commands.

Note: Level 1 authentication in ELF does not require this step.