Macro-based automation
As the name implies, macro-based automation requires a macro to
automate the login process. The macro is responsible for obtaining
the user's host credentials and passing that information to the host
for authentication. The host credentials are based on one of the following
user identity types:
- local system ID: the user's local operating system ID. Web Express Logon currently supports Microsoft Active Directory (Windows Domain). Z and I Emulator for Web will use native code to obtain a user's local Windows domain ID when User Identity Type is set to "Local System ID" in the Express Logon session properties panel. To use this option, the "WindowsDomain" HTML parameter must be set to contain the name of the Windows Domain(s) to which the end users belong. Multiple domains must be separated by commas.
- network ID: the user's network security application ID or client certificate. Web Express Logon currently supports IBM Tivoli Access Manager and Netegrity Siteminder.
- Portal ID: the user's Portal Server ID. Web Express Logon currently supports Portal Server, a component of IBM WebSphere Portal.
 |
If you plan for Z and I Emulator for Web to acquire the user's credentials from a different application than the ones supported by Web Express Logon, you will need to create your own plug-in. For more information, refer to Customizing Web Express Logon. |
Macro-based automation relies on the following four key components
and the interactions that take place among them. Not all environments
that use macro-based automation use all four components:
- login macro
- Credential Mapper Servlet (CMS)
- Network Security plug-in
- Host Credential Mapper (HCM) database
The login macro automates the end-to-end process of the client sending the HTTPS request to the CMS, the CMS responding with the needed credentials, and the macro inserting the user's credentials in the proper fields to allow authenticated logon. You must record the login macro while you are in an active session. It initiates at the time the user attempts to access the host session, either automatically or manually (depending on your configuration).
The CMS is supplied with Z and I Emulator for Web and must be deployed to
a J2EE-compliant HTTP server. At a high level, the CMS is responsible
for determining the client's identity and returning the host credentials
to the client as an XML document.
|
The CMS is not required if using the Portal Credential Vault as your HCM database. This is because the Z and I Emulator for Web portlet is designed to allow the Web Express Logon macro to acquire the user's credentials directly from Portal Server. |
Z and I Emulator for Web provides two Network Security plug-ins, one for
each of the two supported network security applications — IBM
Tivoli Access Manager and Netegrity Siteminder. The primary function
of the Network Security plug-in is to acquire the user's network ID,
which may be gleaned from the HTTP header of the incoming HTTP request
object.
|
The Network Security plug-in does not apply to Microsoft Active Directory (Windows Domain), Portal Server, or Certificate-based Web Express Logon. For Microsoft Active Directory, the Windows login ID is used to identify the user. For Portal Server, the Portal ID is used to identify the user. For Certificate-based Web Express Logon, the client certificate is used to identify the user. |
The HCM database is a back-end repository that maps users' network
IDs to their host credentials. This repository can be one of the following:
- a JDBC database such as one created with IBM WebSphere DB2
- Portal Server Credential Vault
The following examples show you how the key components discussed above interact together, beginning at the point the user attempts to open a Z and I Emulator for Web session and initiate the login macro. If the macro is not configured to auto-start, the user will need to start it manually.