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.
User identity type is a configurable option in session properties.
|
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 Digital Certificate Access Server (DCAS) and Vault plug-ins
provided with Web Express Logon and
Z and I Emulator for Web portlets are designed
to work with these repositories. Another possibility for a repository
is an LDAP directory. However, using LDAP as your HCM database requires
you to write your own plug-in. For more information, refer to
Customizing Web Express Logon.
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.