Z and I Emulator for Web offers three types of Express Logon:
Web Express Logon
Certificate Express Logon
Reuse Active Credentials
Reuse Active Credentials provides automated authentication on all emulation platforms. It is not as comprehensive as Web Express Logon but does not require any special network configuration. If a new connection is made to a host and a user has already authenticated to that host somehow, those credentials are applied to the new connection. The credentials are maintained for as long as Z and I Emulator for Web is running in the JVM. The credentials are only stored in Java memory and once the JVM closes they will have to be re-entered when Z and I Emulator for Web is restarted.
Although all three types of Express Logon allow users to log on to a host system without having to enter a user ID and password, they have different requirements for session type, client certificates, and SSL configuration. Certificate Express Logon works exclusively with 3270 session types and requires client-side certificates and an SSL connection to a TN3270 server. Web Express Logon and Reuse Active Credentials offer a wide variety of styles that function with all Z and I Emulator for Web session types (not just 3270 emulation). Certificate Express Logon requires a macro to log on to the host application and then distribute that macro to the clients. Web Express Logon and Reuse Active Credentials may or may not require a macro, depending on your environment.
|Do not confuse Certificate Express Logon with the type of macro-based Web Express Logon that uses client-side certificates. Certificate Express Logon requires a client-authenticated 3270 session connection to a TN3270 server, whereas certificate-based Web Express Logon requires an HTTPS connection to a Web server that is configured for SSL and client authentication. For more information, refer to the Web Express Logon Reference.|
Web Express Logon provides automated authentication on all emulation platforms and works in the following environments:
Web Express Logon currently offers the following two styles of logon automation:
Each style has its own variations. The style of logon automation that best suits your environment depends on your host and session type. If your host allows the client to supply the needed host credentials at the time the connection is established (for example, during the telnet negotiation via a Kerberos passticket), connection-based automation is the appropriate style to use. However, if the host does not allow the client to supply the needed host credentials at time the connection is established, the host must send a login screen to authenticate the client. Since automating this login screen requires a macro, macro-based automation is the appropriate style. The macro populates the screen's credential fields with the appropriate user information and then transmits this information to the host for authentication.
For a detailed description of Web Express Logon, including an overview, a discussion of how to plan for and implement Web Express Logon, refer to the Web Express Logon Reference.
Certificate Express Logon allows users running a 3270 client session to log on to a host system without having to enter their credentials. The host session must be configured for SSL and client authentication. This means the client must have a valid client certificate. The SSL connection must be made to one of the supported TN3270 servers.
In order to use Certificate Express Logon, you must configure the telnet servers and the z/OS system that you are accessing. The information in the Z and I Emulator for Web documentation describes only what you need to configure for Z and I Emulator for Web. Refer to the following telnet server and z/OS documentation for configuration information:
Reuse Active Credentials provides automated authentication on all emulation platforms. This method of automated authentication allows a user to keep sign on credentials active for as long as Z and I Emulator for Web is running in the JVM. The credentials are only stored in Java memory and once the JVM closes they will have to be re-entered.