Web Express Logon (WEL)

 

+
Search Tips   |   Advanced Search

 

Contents

  1. Overview
  2. Planning for implementation
  3. Implementation
  4. How to create a WEL logon macro
  5. Network Security Plugin
  6. Credential Mapper Plugins
  7. Initialization parameters
  8. Credential Mapper selection
  9. Create SSL key database (DCAS only)
  10. Enable SSL security

 

Overview

Web Express Logon (WEL) allows one to authenticate users of HATS applications, providing them with single signon capability.

Web Express Logon or WEL is the specific ability of an end-user to access host systems and host applications without the requirement of providing additional security credentials. It provides a means for a HATS application to accept user credential information previously authenticated by a network security layer, and use it to generate and use host credentials to be used by the HATS application instead of requiring a HATS end user to navigate logon screens.

WEL works in conjunction with your company's network security application to maintain company security while allowing users to log on to host systems without having to re-enter their user IDs and passwords.

Note that for WEL to work, a user's login/password for the Portal will need to be the same as the user's login/password for the backend 400 application.

A variant called Certificate Express Logon is also supported which allows authentication by way of X.509 certificates rather then by network security applications.

If you click the Use Web Express Logon check box on the Security tab of the Connection editor and then click the Configure Web Express Logon button, the Web Express Logon editor is opened. This editor has the following three tabs:

Macro-based automation style of Web Express Logon allows you to use a network security application such as (IBM Tivoli Access Manager). You can also use a certificate-based authentication to configure WEL or you can create your own plug-in to work in your environment.

Macro-based automation relies on the following four key components and the interactions that take place among them:

The CM is supplied with HATS. At a high level, the CM has two primary roles:

  1. Request the client's credentials (called a network ID)

  2. Respond with the host access credentials, which consist of the host ID and a password or passticket, depending on the type of CMP.

To carry out the request and response process, the CM calls upon the Network Security plug-in to acquire the user's network ID from the network security application. Then the CM calls upon the CMP to acquire the user's host access credentials.

The login macro is recorded while you are in an active session (meaning you have your terminal open and your host session is connected). It initiates at the time the user attempts to access the host session, either automatically or manually (depending on your configuration). In broad terms, it automates the end-to-end process of the client sending the HTTPS request to the CM, the CM responding with the needed credentials, and the macro inserting the user's credentials in the proper fields to allow authenticated logon.

The CMP is a back-end repository that maps users' network IDs to their host IDs. This repository can be a JDBC database such as IBM DB2. The Digital Certificate Access Server (DCAS) and Vault plugins provided with Web Express Logon are designed to work with such a database. Another possibility for a repository is an LDAP directory. However, using LDAP as your CMP requires you to write your own plug-in.

 

Planning for implementation

There are certain things you need to consider while you are planning your setup and configuration to use WEL in your HATS project. The following is a list of what information you'll need to obtain:

 

Implementation

Once you have obtained the information to begin setting up WEL, you will need to do the following:

 

How to create a WEL logon macro

Perform the following steps to create a WEL logon macro:

  1. From HATS Project View, select the project connection from the Connection folder

  2. From the HATS toolbar, start a Terminal session.

  3. Click on the Record Macro icon

  4. Navigate to the screen that contains the user ID input field.

  5. Select Add Prompt Action icon from the toolbar, and the Add Prompt Action wizard appears. Fill in the fields.

  6. Select Use Web Express Logon in the Add Prompt Action dialog.

  7. When you have completed the login process, click the Stop Macro icon and the Save Macro.

After the macro has been recorded and saved, you need to configure Hats to invoke the macro. There are three methods which you can use:

 

Network Security Plugin

The following Network Security plugins can be selected for WEL. You can only have one security plugin per .ear file. Select from the drop-down list beside Plugin type to display the following list:

The WebSphere Portal Network Security Plugin will only appear in the if you are working with a HATS portlet project.

 

Credential Mapper Plugins

The following built-in Credential Mapper plugins are configured for WEL. Click the Add button then select Add built-in Credential Mapper plugin to choose from the following list:

The WebSphere Portal Credential Vault Credential mapper will only appear in the Add built-in Credential Mapper plugin dialog for a Portlet project.

You also have the choice of adding a custom Credential Mapper by selecting Add custom Credential Mapper plugin and entering the name of the fully qualified plugin in the text box.

Once you have selected your Credential Mapper plugin, the details of such as class, name, description and author, will be filled in in the Details section. The Initialization section will display a set of parameters configured for the plugin you selected. By clicking the Add button, you can specify additional parameters for your plugin. You can also select Remove to remove selected parameters. Only parameters which are not required can be removed.

 

Initialization parameters

DCAS parameters for DCAS/RACF/JDBC Credential Mapper plugin

For solutions that use z/OS and DCAS, add the DCAS plugin parameters. Adding these parameters allows the CMP to map the user's network ID to his host ID and then get a passticket from the DCAS application running on the host. A passticket is a credential that is similar to a password, however a passticket expires after a certain amount of time and is used only one time. DCAS requires a Security Access Facility (SAF)-compliant server product, such as an IBM Resource Access Control Facility (RACF) security server, that supports passticket generation.

Required DCAS parameters: The following two Host Credential plug-in parameters allow the client to connect to the DCAS server securely:

CMPI_DCAS_KEYRING_FILE

This parameter specifies a keyring database. A keyring must be specified to provide access to the DCAS client certificate as well as the DCAS server's certificate. The certificates establish a client authenticated secure connection with the DCAS server. This parameter is a file reference to the keyring to be used. The DCAS plug-in is the DCAS client. The keyring file must be stored in the .ear.

CMPI_DCAS_KEYRING_PASSWORD

This parameter specifies the password for the keyring database.

The following parameters are designed to work with your JDBC database credential mapper. Using this type of network-accessible database provides you with a flexible and secure means of associating user's network IDs to their host IDs. By storing all the relevant access information, you can configure access to an existing database or point to a newly created database. The level of security for the database varies according to database vendor.

CMPI_DCAS_DB_ADDRESS

This is a URL string that provides the address of the database.

CMPI_DCAS_DB_NET_DRIVER

This string contains the name of the class that acts as the network database driver. An example of this string is COM.ibm.db2.jdbc.net.DB2Driver. The location of this class is assumed to be in the existing class path.

CMPI_DCAS_DB_USERID

ID of the user account to use when accessing the database.

CMPI_DCAS_DB_PASSWORD

Password of the user account to use when accessing the database.

CMPI_DCAS_DB_TABLE

This entry identifies the table to use for the needed query.

The following four parameter values should match the column names in your credential mapper database and should clearly indicate the contents of the columns. With some databases, such as IBM DB2, the four column headings in the database must be in all upper case, for example, NETWORKID, HOSTADDRESS, APPLICATIONID, and HOSTID.

CMPI_DCAS_DB_NETID_COL_NAME

This entry identifies the name of the column that contains the network ID value (NETWORKID).

CMPI_DCAS_DB_HOSTADDR_COL_NAME

This entry identifies the name of the column that contains the host address value (HOSTADDRESS).

CMPI_DCAS_DB_HOSTAPP_COL_NAME

This entry identifies the name of the column that contains the host application value (APPLICATIONID).

Application ID is only used for 3270 host types.

CMPI_DCAS_DB_HOSTID_COL_NAME

This entry identifies the name of the column that contains the user's host identification value (HOSTID).

Based on the information provided by the parameters above, you can make an SQL query of the database to get the host ID. This query uses the network ID, the host address, and the host application as keys for the query. The result is identified in the Host Identification column. Assuming that the query is successful, a call is made to the DCAS server to request the passticket.

Optional DCAS parameters: The following DCAS parameters are optional:

CMPI_DCAS_TRACE_LEVEL

This parameter specifies the trace level for the DCAS plug-in. The trace messages are logged to the HATS trace file. Trace level values include the following:

0 None No tracing. Default.
1 Minimum Trace APIs and parameters, return values, and errors.
2 Normal Trace Minimum plus internal APIs and parameters and informational messages.
3 Maximum Trace Normal plus Java exceptions.

CMPI_DCAS_HOST_PORT

The DCAS host address is determined based on the destination host specified in the request. The default port address of 8990 is used, but you may override it using this parameter.

CMPI_DCAS_HOST_ADDRESS

The default DCAS host address is determined based on the destination host specified for the HATS connection.

CMPI_DCAS_USE_WELLKNOWN_KEYS

This parameter indicates whether the WellKnownTrustedCAs.class should be used to look up the DCAS server certificate or not. The default is true.

CMPI_DCAS_VERIFY_SERVER_NAME

This parameter indicates if the server host name in the certificate must be verified in addition to the certificate validation. The default is false.

CMPI_DCAS_REQUEST_TIMEOUT

This parameter specifies the passticket request timeout in milliseconds. It should be less than the macro time-out value. The default is 50000.

CMPI_DCAS_DB_PRESERVE_WHITESPACE

This parameter indicates whether to trim white space from the credential request parameters or not. If true, the white space is not trimmed. The default is false.

 

DCAS parameters for Certificate-based DCAS/RACF Credential Mapper plugin

Required DCAS parameters:The following two Host Credential plugin parameters allow the client to connect to the DCAS server securely:

CMPI_DCAS_KEYRING_FILE

This parameter specifies a keyring database. A keyring must be specified to provide access to the DCAS client certificate as well as the DCAS server's certificate. The certificates establish a client authenticated secure connection with the DCAS server. This parameter is a file reference to the keyring to be used. The DCAS plugin is the DCAS client. The keyring file must be stored in the .ear.

CMPI_DCAS_KEYRING_PASSWORD

This parameter specifies the password for the keyring database.

Optional DCAS parameters: The following DCAS parameters are optional:

CMPI_DCAS_TRACE_LEVEL

This parameter specifies the trace level for the DCAS plugin. The trace messages are logged to the HATS trace file. Trace level values include the following:

  • 0 = None: No tracing. Default.

  • 1 = Minimum: Trace APIs and parameters, return values, and errors.

  • 2 = Normal: Trace Minimum plus internal APIs and parameters and informational messages.

  • 3 = Maximum: Trace Normal plus Java exceptions.

CMPI_DCAS_HOST_PORT

The default port address of 8990 is used, but you may override it using this parameter.

CMPI_DCAS_HOST_ADDRESS

The default DCAS host address is determined based on the destination host specified for the HATS connection.

CMPI_DCAS_USE_WELLKNOWN_KEYS

This parameter indicates whether the WellKnownTrustedCAs.class should be used to look up the DCAS server certificate or not. The default is true.

CMPI_DCAS_VERIFY_SERVER_NAME

This parameter indicates if the server host name in the certificate must be verified in addition to the certificate validation. The default is false.

CMPI_DCAS_REQUEST_TIMEOUT

This parameter specifies the passticket request timeout in milliseconds. It should be less than the macro time-out value. The default is 50000.

 

Vault parameters for JDBC Vault Credential Mapper plugin

Add Vault parameters for CMPIVaultPlugin. For environments that use JDBC-based Vault host security, add the Vault plugin parameters. This model is identical to the database mechanism used to associate network IDs and host IDs in the DCAS passticket environment. The only difference is that Vault-style authentication requires the CMPI_VAULT_DB_HOSTPW parameter

Required Vault parameters: The following Vault parameters are required:

CMPI_VAULT_DB_ADDRESS

This is a URL string that provides the address of the database. An example of this string is jdbc:db2://dtagw:6789/CMTEST.

CMPI_VAULT_DB_NET_DRIVER

This string contains the name of the class that acts as the network database driver. An example of this string is COM.ibm.db2.jdbc.net.DB2Driver. The location of this class is assumed to be in the existing class path.

CMPI_VAULT_DB_USERID

ID of the user account to use when accessing the database.

CMPI_VAULT_DB_PASSWORD

Password of the user account to use when accessing the database.

CMPI_VAULT_DB_TABLE

This entry identifies the table to use for the needed query.

The following five parameter values exactly match the column names in your credential mapper database.

CMPI_VAULT_DB_NETID_COL_NAME

This entry identifies the name of the column that contains the network ID value (NETWORKID).

CMPI_VAULT_DB_HOSTADDR_COL_NAME

This entry identifies the name of the column that contains the host address value (HOSTADDRESS).

CMPI_VAULT_DB_HOSTAPP_COL_NAME

This entry identifies the name of the column that contains the host application value (APPLICATIONID).

Application ID is only used for 3270 host types.

CMPI_VAULT_DB_HOSTID_COL_NAME

This entry identifies the name of the column that contains the user's host identification value (HOSTID).

CMPI_VAULT_DB_HOSTPW_COL_NAME

This entry identifies the name of the column that contains the user's host password (PASSWORD).

Based on the information provided by the parameters above, you can make an SQL query of the database to get the host ID. This query uses the network ID, the host address, and the host application as keys for the query. The result is identified in the Host Identification column. Assuming that the query is successful, the user ID and password are returned.

Optional Vault parameters: The following Vault parameters are optional:

CMPI_VAULT_TRACE_LEVEL

This parameter specifies the trace level for the Vault plug-in. The trace messages are logged to the HATS trace file. Trace level values include the following:

  • 0 = None: No tracing. Default.

  • 1 = Minimum: Trace APIs and parameters, return values, and errors.

  • 2 = Normal: Trace Minimum plus internal APIs and parameters and informational messages.

  • 3 = Maximum: Trace Normal plus Java exceptions.

CMPI_VAULT_DB_PRESERVE_WHITESPACE

This parameter indicates whether to trim white spaces from the credential request parameters or not. If true, the white spaces are not trimmed. The default is false.

 

WebSphere Portal Credential Vault Credential mapper

This initialization parameter will only appear in the if you are working with a HATS portlet project.

VAULT_ID

Vault slot ID that will retrieve a passive user-password credential from a vault slot.

Create a vault slot for each user that you want to be able to use WEL. A user's login/password for the Portal will need to be the same as the user's login/password for the backend 400 application.

 

Credential Mapper selection

The following describes which Credential Mapper requests will be handled by this plugin:

 

Authentication type:

Authentication type Description
AuthType_3270 Identifies the credentials to be used with a 3270 emulation
AuthType_5250 Identifies the credentials to be used with 5250 emulation
AuthType_VTHost Identifies the credentials to be used with VT emulation

 

Host mask:

Host mask Value matched
*.raleigh.ibm.com Matches all addresses that end with .raleigh.ibm.com
ralvm* Matches all addresses that start with ralvm
* Matches all
*xyz* Matches any host address that contains xyz

 

Create SSL key database (DCAS only)

To communicate with a DCAS server, an SSL connection must be established using client authentication. This requires you to create a key database file. To create the file, use the HATS Certificate Management GUI. This key database file must contain the DCAS client's personal certificate and the DCAS server's certificate (public key) information. Also, the DCAS client certificate must be added/imported to the DCAS server's keyring for SSL client authentication.

If you already have an older certificate that was created using the iKeyman utility, you may import it. Personal server certificates that were created with the old system cannot be easily exported from the old and imported into the new. There is however a way which you can do this:

  1. Import the entire old format .kdb file into the new iKeyman

  2. Export the desired certificates (such as, DCAS server certificate) to a .p12 format certificate.

  3. Import the .p12 file into the new format .p12 keyring file.

To create a new keyring database called HatsWelKeys.p12 file that will be specified in the CMPI_DCAS_KEYRING_FILE parameter in your .xml file, take the following steps on a Windows machine.

  1. Click...

    Start | Programs | IBM WebSphere HATS | Certificate Management | Key Database File | New

  2. For the Key database type, select PKCS12.

    For File Name, type HatsWelKeys.p12.

    For Location, type...

    C:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1\wstools\eclipse\plugins\com.ibm.hats\

    You will have to manually put this in your .ear file. You may choose a different name and location.)

  3. Click OK.

  4. Type the password and make a note of it.

  5. Click OK.

  6. Add the DCAS server's certificate to the key database. Be sure that the key database content is for the signer certificate. If it is not, select the pull-down menu and change it. Then select Add.

    1. Select Binary DER data for the Data type. If the server certificate is in ASCII format, select Base64-encoded ASCII data.

    2. Type the file name in the Certificate file name field.

    3. Type the path name in the Location field.

    4. Click OK.

    5. Enter a label for the certificate and click OK.

  7. Add the DCAS client's certificate to the key database.

    1. Change the Key database content to Personal Certificates and click Import.

    2. Select PKCS12 for the Key file type.

    3. Type the client certificate's p12 file name in the File Name field and the path name in the Location field.

    4. Click OK and enter the client certificate PIN.

    5. Click OK.

  8. Exit the Certificate Management GUI.

 

Enable SSL security

HATS supports SSL between applications and telnet servers.

If you click the SSL enabled check box in the Security tab of the connection file, you request that data flowing over the connection to be encrypted to secure the connection.

HATS uses Host On-Demand to provide connection support from HATS applications to 3270 and 5250 applications using Telnet protocols. HATS uses the SSL support provided by Host On-Demand for securing these connections. Using a secure connection over SSL encrypts data flowing over the connection and thus protects it against observation by a third party.

For a connection to be secured, both the HATS application and the Telnet server it is connected to must support SSL. To secure the connection, the Telnet server must provide a certificate, which is used in encrypting the data. This certificate uniquely identifies a machine on one end of the connection.

Security between the end user and the HATS application depends on the WebSphere Application Server configuration. The SSL configuration of HATS is between the HATS application and the host application.

See also:

  1. WebSphere Application Server security
  2. IBM HTTP Server security

HATS verifies that the certificate is signed by a well-known certificate authority (for example: Thawte, Verisign, and RSA). If the server has a certificate signed by a well-known certificate authority, HATS will already have the signer certificate in the keyring file built in to HATS. The certificate is guaranteed to be unique and secure. If the Telnet server has a self-signed certificate, the administrator of the server, generated the certificate based on his or her own information without using a certificate authority. In that case, HATS must have a copy of the self-signed certificate to secure the connection. You can obtain a copy of the self-signed certificate (in .der or .cer format) and import the function. If it is a non-well-known certificate authority, a signer certificate must be imported.

If a certificate is required by HATS, you can click Import in the Security tab of the connection file editor to import the required certificate from the Telnet server. When the certificate is imported, HATS builds a database called CustomizedCAs.class. The CustomizedCAs.class file is contained in the CustomizedCAs.jar. The database contains the certificate that you import. The certificate becomes a part of the HATS project, and it is packaged with the rest of the project files when you assemble the project.

When a HATS application that enables SSL security is deployed to WebSphere Studio, the application War Classloader Policy setting in WebSphere Application Server must be set to "Application" (the default setting is "Module").

 

See also

  1. Create custom plug-ins for Web Express Logon
  2. Sample Web Express Logon plug-in
  3. Programming in HATS portlets
  4. Programming in HATS portlets
  5. HATS Studio files
  6. HATS for WebSphere Studio
  7. Glossary
  8. Incorporate macros
  9. HATS Studio Connections
  10. Migrate to HATS Version 5.0
  11. Sample modified Integration Object template
  12. HATS Programming
  13. Create Web Services
  14. Install HATS
  15. Create and organize projects
  16. Host Access Transformation Services Troubleshooting
  17. Create and Using a HATS EJB application
  18. Customize your HATS project
  19. Messages

 

Home