Before using this information and the product it supports, read the information in Appendix D. Notices.
This edition applies to Version 8.0 of IBM(R) WebSphere Host On-Demand (program number 5724-F69) and to all subsequent releases and modifications until otherwise indicated in new editions.
This book describes a step-by-step approach to understanding, planning for, implementing, and troubleshooting Web Express Logon. It is written for administrators who are interested in learning about and implementing Web Express Logon in their computing environment. It contains eight parts:
For more information about Web Express Logon, the Host On-Demand Information Center at http://www.ibm.com/software/webservers/hostondemand/library/v8infocenter/ features the following:
The following typographic conventions are used in Host On-Demand Web Express Logon Reference:
| Convention | Meaning |
|---|---|
| Monospace | Indicates text you must enter at a command prompt and values you must use literally, such as commands, functions, and resource definition attributes and their values. Monospace also indicates screen text and code examples. |
| Italics | Indicates variable values you must provide (for example, you supply the name of a file for file_name). Italics also indicates emphasis and the titles of books. |
| > | When used to describe a menu, shows a series of menu selections. For example, "Click File > New" means "From the File menu, click the New command." |
When used to describe a tree view, shows
a series of folder or object expansions. For example, "Expand HODConfig
Servlet > Sysplexes > Plex1 > J2EE Servers > BBOARS2" means:
|
|
|
This graphic is used to highlight notes to the reader. |
|
|
This graphic is used to highlight tips for the reader. |
|
|
This graphic refers to connection-based automation for IBM eServer iSeries environments that support Kerberos authentication. |
|
|
This graphic is used to indicate troubleshooting tips for the reader. |
In the age of e-business on demand, finding ways to simplify the user experience while maintaining company security can be a real challenge. For example, many companies would like to decrease the number of IDs and passwords that their users have to manage, but they also realize that allowing users to access company resources without proper identification risks company security.
Several products exist in the marketplace that claim to solve the multiple logon issue and maintain security at the same time. However, these products generally apply to Web-based applications only and do not address logon processes for legacy hosts and host-based applications. In other words, in host-based applications that do not use HTML or XML, automating the logon process requires being able to intercept the telnet data stream. Because of its unique position to work with individual screens and the ability to substitute fields in the data stream, Host On-Demand is an ideal candidate to address multiple logon issues in companies whose users access host systems via browser-based terminal emulation.
Web Express Logon 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. It has several benefits, including the following:
Host On-Demand offers two types of Express Logon:
Web Express Logon is a new feature available with Host On-Demand Version 8. Certificate Express Logon, formerly known as Express Logon Feature (ELF), has been available since Host On-Demand Version 5. Although the name has changed, Certificate Express Logon functions the same as ELF did in earlier versions and requires the same configuration.
Although both Web Express Logon and Certificate Express Logon allow users to log on to host systems without having to enter their user IDs and passwords, the two types of Express Logon have different requirements. For example, Certificate Express Logon requires client-side certificates for user authentication and works exclusively with z/OS and OS/390 host systems. In order to use Certificate Express Logon, the client must have a valid client certificate, and the SSL connection must be made to one of the supported TN3270 servers. Web Express Logon, however, does not require SSL configuration nor client-side certificates, and it can function on multiple platforms. Which type of Express Logon you choose depends on your environment and your company needs. For more information about Certificate Express Logon, refer to the Setting up and Using the IBM Express Logon Feature white paper.
The overall goal of Web Express Logon is to provide an automated way for users to log on to hosts and host-based applications without having to provide an additional ID. It is designed to function within a wide range of computing environments. Your particular environment determines the way in which you plan for, implement, and use Web Express Logon.
Web Express Logon currently offers two styles of logon automation:
The style of logon automation that best suits your environment depends on your host type. Macro-based automation is for environments of varying host types that are not using Kerberos authentication. As the name implies, it requires you to create a macro to perform logon automation. Connection-based automation, on the other hand, is only for IBM eServer iSeries host environments that support Kerberos authentication. It does not require a macro to perform logon automation but instead relies on a telnet feature to supply the user's necessary logon information.
The following sections provide more details about Web Express Logon's macro-based and connection-based automation:
In order to use the macro-based automation style of Web Express Logon, you must have a network security application in place. Host On-Demand provides out-of-the-box support for three common network security applications without requiring additional coding: IBM Tivoli Access Manager, Netegrity Siteminder, and Microsoft Active Directory (Windows Domain). If you have a different network security application, you will need to create your own plug-in to work in your environment. 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:
The CMS is supplied with Host On-Demand and must be deployed to a Web server or some type of Web application framework. At a high level, the CMS has two primary roles: (1) request the client's credentials (called a network ID) and (2) respond with the host access credentials, which consist of the host ID and a password or passticket, depending on the type of HCM. In order to carry out the request and response process, the CMS calls upon the Network Security plug-in to acquire the user's network ID from the network security application. Then, the CMS calls upon the HCM to acquire the user's host access credentials. It then returns the host access credentials to the Host On-Demand client in the form of an XML document.
The login macro is recorded 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). In broad terms, it 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.
The HCM 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 plug-ins provided with Web Express Logon are designed to work with a such a database. Another possibility for a repository is an LDAP directory. However, using LDAP as your HCM requires you to write your own plug-in. For more information, refer to Customizing Web Express Logon.
Figure 1 illustrates the overall flow of macro-based automation by showing you the key components discussed above and how they interact together to achieve logon automation:
The following are the steps that take place at the point when a user attempts to open a Host On-Demand session and initiates the login macro. If the macro is not configured to auto-start, the user will need to start it manually. The numbers in the list correspond to the numbers in Figure 1:
The login macro automatically inserts the user's credentials in the logon screen fields without user intervention. Now the user is fully authenticated and can proceed with the session.
Macro-based automation has been successfully tested with the following applications:
|
|
The macro-based automation version of Web Express Logon can function with other applications that are not listed here. |
Connection-based automation works in iSeries environments that meet the following criteria:
Working in conjunction with Kerberos-based network authentication and an IBM technology called Enterprise Identity Mapping (EIM), this iSeries environment already has the capability to provide single sign-on. Web Express Logon simply extends this capability by allowing Host On-Demand to use the existing methodology for acquiring credentials to allow users to bypass the host session login screen. Because it works within your existing environment, connection-based automation does not require the use of a CMS, a login macro, the Network Security plug-in, nor the HCM.
With connection-based automation, Host On-Demand sessions allow users to bypass the logon screen by using the user ID and passticket credentials obtained when users connect to target iSeries systems from client workstations that are on a Windows Domain. The Enterprise Identity Mapping (EIM) feature of OS/400 calculates the target iSeries user profile to use, and the network authentication service of OS/400 defines the Kerberos realms to trust.
Connection-based automation relies on the following three key components:
The Windows domain controller gives users access to the network, and the Key Distribution Center (KDC) gives users access to individual resources within that network. The KDC gives users access to these resources by granting them Kerberos passtickets. To illustrate this concept with an analogy, think of an individual attempting to enter a building. Once the user is authenticated to enter the building (by the domain controller), he attempts to enter a room within the building. However, at this point, he is challenged to provide additional credentials. He requests access to the room (from the KDC) and is then authenticated to enter the room (with a Kerberos passticket).
Figure 2 illustrates the overall process of connection-based automation in an iSeries environment with Kerberos authentication enabled:
The following list shows you the steps that take place during connection-based automation. The numbers in the list correspond to the numbers in Figure 2:
Having a clear understanding of your environment and how you plan to implement Web Express Logon in your environment will save you valuable time in the implementation phase. Be sure that you take time to develop your strategy and gather the necessary resources and skills. A firm plan is key to a successful implementation.
We recommend that you begin planning by taking the following steps:
As described in the introduction, Host On-Demand offers two styles of logon automation: macro-based automation and connection-based automation. The style of logon automation that best suits your environment depends on your host type. Macro-based automation is for environments of varying host types that are not using Kerberos authentication. Connection-based automation, on the other hand, is only for IBM eServer iSeries host environments that support Kerberos authentication.
Credential challenges are the times at which users are prompted to provide IDs and passwords. The first step is to evaluate your existing network infrastructure and identify which credential challenges exist for your users. Approach this step by simulating a typical day and identifying all the points at which users are prompted to provide credentials. For example, in a corporate environment, users may have to provide credentials when attempting to access any of the following resources:
At this point, you should know which style of logon automation is appropriate for your environment and what components are necessary to implement Web Express Logon. Before you can successfully plan your deployment strategy and estimate the scope of implementation, take a moment to take an inventory of your environment and answer the following questions according to your style of logon automation:
Now that you have evaluated your need for a Web Express Logon solution, chosen the style of logon automation that best works in your environment, and taken an inventory of your company's environment and resources, you can begin developing your deployment strategy. Consider issues such as how many/which users will be affected by this implementation, which skills are required for a successful implementation, and how many people you will need to participate in the setup process.
|
|
This step does not apply to iSeries platforms that support Kerberos authentication. |
If you are in an environment that does not support Kerberos authentication, you must have an HCM in place. An HCM is a back-end repository that associates users' network IDs to their host IDs. This repository can be a JDBC database such as IBM DB2. The DCAS and Vault plug-ins provided with Web Express Logon are designed to work with a such a database. Another possibility for a repository is an LDAP directory. However, using LDAP as your HCM requires you to write your own plug-in. For more information, refer to Customizing Web Express Logon. The CMS queries this repository during the logon process.
Host On-Demand provides a Credential Mapper Servlet (CMS) that supports three network security applications:
If you do not have one of these three network security applications, you will need to customize your own version of the CMS. For more information, refer to Customizing Web Express Logon.
Take the following steps when using one of the three versions of the CMS shipped with Host On-Demand. They are packaged as individual WAR files on the Host On-Demand Version 8 CD.
The three WAR files are located in the cdimage\apps\wel subdirectory. Choose the one that matches your network security application:
Once you select the WAR file that matches your environment, unpack it and view its contents. In addition to several CLASS files, you will see the following four files:
The web.xml file is the servlet configuration file that you will edit in future steps. The other two XML files (DCAS.xml and Vault.xml) are sample files that we have provided to help you better understand DCAS and Vault parameters and their values. We also recommend that you use these files as a reference when you edit the web.xml file. Finally, the was.policy file is for IBM WebSphere Application Server only. It contains the required permissions for the CMS when Java 2 security is enabled. For more information, refer to Troubleshooting Web Express Logon.
The web.xml file contains three default INIT parameters. INIT parameters are what the CMS configures to work in your environment. They adapt the servlet to your environment.
<init-param>
<param-name>CMPINetworkSecurity</param-name>
<param-value>com.ibm.eNetwork.security.sso.cms.CMNPIAccessManager
</param-value>
</init-param>
|
|
The Network Security plug-in does not apply to the Microsoft Active Directory (Windows Domain) web.xml file. This is because the Windows login ID is used as the network ID. |
|
|
Using this echo parameter is optional and can help you confirm that you've deployed your servlet correctly in later steps. |
init-param> <param-name>CMPICredentialMappers</param-name> <param-value>echo</param-value> </init-param>
<init-param> <param-name>echo</param-name> <param-value>com.ibm.eNetwork.security.sso.cms.CMPINetEcho,AuthType_All, *</param-value> </init-param>
Now that you have viewed the CMS-related INIT parameters, you are ready to edit the web.xml file.
|
|
In the web.xml file, do not change
the following:
|
To edit the CMS-related parameters, take the following steps:
|
|
Add the following two optional debugging parameters to help you troubleshoot. |
<init-param> <param-name>CMPICredentialMappers</param-name> <param-value>CMPIDCASPlugin, CMPIVaultPlugin</param-value> </init-param>
<init-param> <param-name>CMPIDCASPlugin</param-name> <param-value>com.ibm.eNetwork.security.sso.cms.CMPIDCAS, AuthType_3270Host, *</param-value> </init-param>
init-param> <param-name>CMPIVaultPlugin</param-name> <param-value>com.ibm.eNetwork.security.sso.cms.CMPIVault, AuthType_ALL, *</param-value> </init-param>
The parameter value is a compound value that contains the full class path name of the implementing class, the authentication type to be addressed by the credential mapper, and the host mask. The values are separated by the comma character.
Full class path name
The CMS uses the value of the full class path name to create a class object of the specified type. That object is then used to handle CMS or HCM requests. The specified class file must be in the ...\WEB-INF\classes subdirectory in a loose file (not as a JAR file). From this location, the CMS will be able to access and use it whenever the need arises.
Authentication type
This value is used to identify the type of authentication that the requestor needs. Once you specify the desired authentication type, the CMS can better identify which credential mapper to select to handle the request. You can pair multiple authentication types together to give HCMs the freedom to support multiple authentication types. Use the vertical bar character to join multiple authentication types.
The five identified authentication types are listed in Table 2:
| Authentication type | Description |
| AuthType_3270Host | Identifies the credentials to be used with a 3270 emulation |
| AuthType_5250Host | Identifies the credentials to be used with 5250 emulation |
| AuthType_VTHost | Identifies the credentials to be used with VT emulation |
| AuthType_FTPPassword | Credentials used to access an FTP host |
| AuthType_ConfigServer | Credentials identified by the token used to identify the user to the Host On-Demand configuration server (if you are using the Configuration server-based model |
Host mask
The host mask is a secondary selection criteria used by the CMS to identify the most appropriate credential mapper. This value can contain one or more host addresses. Use the vertical bar character to join multiple addresses. Use the asterisks character to wildcard a host address. The wildcard character may start, end, or start and end a host address.
Table 3 lists valid wild-carded addresses:
| 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 |
For solutions that use z/OS and DCAS, add the DCAS plug-in parameters. Adding these parameters allows the HCM 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.
|
|
To use the DCAS plug-in, you must configure the DCAS server. To configure the DCAS server, refer to the z/OS V1R4.0 Communications Server IP Configuration Reference at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2ZO108, publication number SC31-8776-03. Also refer to the z/OS V1R4 APAR PQ74457 for information on how to configure the DCAS server to function with Web Express Logon. |
|
|
Use the DCAS.xml file located in the WAR file as a reference for adding parameters when editing the web.xml file. |
The following two Host Credential plug-in parameters allow the client to connect to the DCAS server securely:
|
|
You will create this file in Step 3: Create SSL key database (DCAS only).. |
|
|
This parameter should be encrypted using the password encryption tool. It is decrypted by the HCM before using it. For more information about the password encryption tool, refer to Appendix A. Password encryption tool. |
The following parameters are designed to work your JDBC database credential mapper. Using this type of network-accessible database provides you with a flexible and secure means of associating users' network IDs to their host IDs. By storing all the relevant access information in this web.xml file, 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.
If you are using LDAP as your credential mapper, you will need to create your own HCM using Customizing Web Express Logon.
|
|
This parameter should be encrypted using the encrypt password tool. It is decrypted by the HCM before using it. For more information about the password encryption tool, refer to Appendix A. Password encryption tool. |
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.
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.
The following DCAS parameters are optional:
For environments that use JDBC-based Vault host security, add the Vault plug-in 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 in the web.xml file.
|
|
Use the Vault.xml file located in the WAR file as a reference for adding parameters when editing the web.xml file. |
The following Vault parameters are required:
|
|
This parameter should be encrypted by the encrypt password tool. It is decrypted by the HCM before using it. For more information about the password encryption tool, refer to Appendix A. Password encryption tool. |
The following five parameter values should be in all upper case and should exactly match the column names in your credential mapper database. With some databases, such as IBM DB2, the five column headings in the database must be in all upper case, for example, NETWORKID, HOSTADDRESS, APPLICATIONID, HOSTID, and 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.
The following Vault parameters are optional:
Once you have completed editing the web.xml file, you may need to repackage the WAR file. This process depends on the requirements of your Web application server. Consult your product's documentation to learn more about these requirements.
At this point, you are ready to deploy the servlet to the Web server. Refer to your Web server application's documentation for details of how to deploy the servlet.
In order to communicate with a DCAS server, an SSL connection must be established using client authentication. This requires you to create a key database file, for example HODDCAS.p12. To create the file, use the Host On-Demand Certificate Management GUI on Windows and AIX platforms, or use a P12 keyring tool for other platforms. 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.
|
|
For more information
about creating this key database file, refer to the Planning, Installing,
and Configuring Host On-Demand guide, which is located in the Host On-Demand
InfoCenter at Start > Programs > IBM WebSphere Host On-Demand > InfoCenter
or on the Web at http://www.ibm.com/software/webservers/hostondemand/
library/v8infocenter/. |
To create a keyring database called HODDCAS.p12 file that will be specified in the CMPI_DCAS_KEYRING_FILE parameter in your web.xml file, take the following steps on a Windows machine
The Host On-Demand Deployment Wizard allows you to specify how sessions are defined and managed. You can choose from three different configuration models:
If you are using the HTML-based or Combined models, you can create your HTML file as normal. However, for the Configuration server-based model, you must configure the HTML file with additional steps:
WELM051 User name returned from Web Express Logon is not a known Host On-Demand userSelecting this option also requires that you add an additional Vault credential mapper and all of its parameters to your web.xml file. For example, take the following steps:
<init-param> <param-name>CMPICredentialMappers</param-name> <param-value>CMPIDCASPlugin, CMPIVaultPlugin, CMPIConfigServer_ </param-value> </init-param>Add the parameter name for the new parameter value specified above, and change the AUTH type to AuthType_ConfigServer:
<init-param> <param-name>CMPIConfigServer_</param-name> <param-value>com.ibm.eNetwork.security.sso.cms.CMPIVault, AuthType_ConfigServer, *</param-value> </init-param>
ConfigServer=myhodserver.ibm.comwhere myhodserver is the machine you are pointing to with the junction_name.
You must configure your session properties to use Express Logon. You can do this in the following two ways:
The options on the Express Logon window differ depending on the type of session you are configuring. Figure 3 is the Express Logon window for 3270 sessions:
Once you select Yes to enable Express Logon, chose whether or not you want Host On-Demand to use the user's local operating system ID for authentication. Next, type the full URL of the credential mapper server, for example, https://server_name/junction/cm/CredMapper, where
Be sure that the servlet name matches the name in your XML file. For example, if you specify the servlet name in your host session as CredMapper, the code in your XML should look like the following:
<servlet>
<servlet-name>CredMapper</servlet-name>
<display-name>CredMapper</display-name>
<servlet-class>com.ibm.eNetwork.security.sso.cms.CredMapper</servlet-class>The servlet that resides at this URL processes the HTTPS request from the user, performs a lookup, and returns the user's credentials. The Host On-Demand client uses the obtained credentials to automate the login process.
Take the following steps to record the automation macro:
The alternate start screen is a screen from which the user might want to play the macro to log on to the application. If the application has more than one possible start screen, you should identify it during the recording process so that the macro can be played from that screen. For example, the logon process might begin from the USSMSG10 screen or the application logon screen. You may start the logon macro from either the start screen or the alternate start screen. You can designate only one screen as an alternate start screen. There is no alternate start screen after the screen that contains the user ID.
|
|
Click Current only if you will not be using this screen for multiple applications and the location of the user ID field never changes. |
|
|
Click Current only if you will not be using this screen for multiple applications and the location of the password field never changes. |
Unlike macro-based automation, connection-based automation does not require the use of a Credential Mapper Servlet (CMS), a login macro, the Network Security plug-in, nor the Host Credential Mapper (HCM). Instead, it extends the existing single sign-on capability of iSeries environments that meet the following criteria:
You must configure your iSeries environment to use single sign-on capability in order to implement connection-based logon automation.
The iSeries environment provides single sign-on capability by working in conjunction with Kerberos-based network authentication and an IBM technology called Enterprise Identity Mapping (EIM). Host On-Demand uses this existing methodology for acquiring credentials to allow users to bypass the host session login screen.
Both EIM technology and Kerberos are available with Version 5R2 of the OS/400 operating system. EIM is an IBM infrastructure technology that allows you to manage multiple user identities and user registries easily and inexpensively while maintaining secure authentication and authorization. This architecture describes the relationships between individuals or entities in an enterprise and the many identities that represent them within the enterprise. Kerberos, on the other hand, is a network authentication protocol that identifies and authenticates users who request to log on to a network. Together, EIM and Kerberos provide single sign-on capability.
Although this document does not instruct you how to configure your iSeries environment for single sign-on capability, the following resources are available to help you:
Once you have configured your iSeries environment to use single sign-on capability, you are ready to configure Host On-Demand to extend this single sign-on capability. To accomplish this, take the following two steps:
The Host On-Demand Deployment Wizard allows you to specify how sessions are defined and managed. You can choose from three different configuration models:
When using the Configuration server-based model and a network security application such as Tivoli Access Manager, you may be accessing your Host On-Demand pages via a URL such as https://server_name/junction_name/HOD/myhodpage.html, where server_name is the name of the machine running Tivoli Access Manager and junction_name is the junction that you create to point to your Host On-Demand server machine and your HTTP server's port number. If this is the case, Host On-Demand will try to contact the Host On-Demand Service Manager to get your user, group, and session information at the server_name rather than at the junction_name. To remedy this situation, edit the config.properties file found in the HOD directory of your Host On-Demand install directory (\Program Files\IBM\HostOnDemand\HOD\config.properties) by adding this line at the end of the file content:
ConfigServer=myhodserver.ibm.com
where myhodserver is the machine you are pointing to with the junction_name.
Configure your 5250 session properties to use a Kerberos passticket. You can do this in the following two ways:
Once you select to use a Kerberos Passticket, Host On-Demand will be able to retrieve a passticket from a Windows server. This passticket is used to connect to the host system that you identify in the session properties.
AC Gas, Inc. is a fictitious electric and gas company based in a metropolis area. It has over 1000 employees who must connect to host systems and host-based applications throughout the day to access customer and employee records. Using IBM WebSphere Host On-Demand, these employees are able to access the data securely through their Java-enabled browsers and do not have to interact directly with the traditional mainframe green screen.
The company's employees are constantly logging in and out of host sessions and Web applications, forcing them to keep up with several IDs and passwords. They complain that they are continuously prompted to provide their credentials, something they feel takes up valuable time. Also, the company's IT staff is complaining because they receive several calls a day from employees who have forgotten or misplaced their passwords.
Every year, the company executives send out a satisfaction survey to its employees. On this survey, one of the top complaints is the need to log in multiple times per day and having to keep up with multiple IDs and passwords, many of which are different. The executives also noticed that another big complaint is the amount of time employees spend calling the support line to have representatives reset lost passwords. The executives investigate even further and find out that password-related support calls make up over 40% of the total amount of calls, something that is costing the company a sizable amount of money. They immediately begin researching ways to eliminate this costly multiple logon problem. They find several applications that claim to offer a single sign-on solution, but none of them function within the company's host-based infrastructure. They decide to investigate Host On-Demand's Web Express Logon. They start by planning their strategy.
| Component | AC Gas, Inc.'s environment |
| Web Application Server | IBM WebSphere Application Server Version 5.0 |
| Database | IBM DB2 Universal Database Version 7 |
| Network security application | IBM Tivoli Access Manager for e-business Version 4.1 |
| Host OS | z/OS V1R4 with APAR PQ74457 |
| Web server | IBM HTTP Server |
| Host authentication | DCAS |
|
|
Consult the documentation for SQL calls for your database platform. |
Once AC gas, Inc. plans their strategy, they move directly into the implementation phase:
AC Gas, Inc. understands that the Credential Mapper Servlet (CMS) is the core of the credential-mapping framework and must reside on a Web server. Using the Host On-Demand Version 8 CD, they browse to the cdimage\apps\wel subdirectory and locate the amcms.war file. This is the WAR file that is designed to work with Tivoli Access Manager. Next, they unpack the amcms.war file and view its contents in an effort to become more familiar with how it is organized. Their next step is to edit the web.xml file.
Before editing the web.xml file, they gather the list of parameters from Macro-based automation and become familiar with which ones are required and which ones are optional. The following is their web.xml file after customizing it:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app id="WebApp_ID">
<display-name>cms</display-name>
<description>Credential Mapper Servlet</description>
<servlet>
<servlet-name>CredMapper</servlet-name>
<display-name>CredMapper</display-name>
<servlet-class>com.ibm.eNetwork.security.sso.cms.CredMapper</servlet-class>
<init-param>
<param-name>CMPINetworkSecurity</param-name>
<param-value>com.ibm.eNetwork.security.sso.cms.CMNPIAccessManager
</param-value>
</init-param>
<init-param>
<param-name>CMPICredentialMappers</param-name>
<param-value>CMPIDCASPlugin </param-value>
</init-param>
<init-param>
<param-name>CMPI_TRACE_LOG_FILE</param-name>
<param-value>C:\Program Files\IBM\HostOnDemand\HOD\HODWEL.log</param-value>
<description>Credential Mapper Log file name.</description>
</init-param>
<init-param>
<param-name>CMPI_CMS_TRACE_LEVEL</param-name>
<param-value>3</param-value>
<description>DCAS Trace level. 0=none,1=min,2=normal,3=max.</description>
</init-param>
<init-param>
<param-name>CMPIDCASPlugin</param-name>
<param-value>com.ibm.eNetwork.security.sso.cms.CMPIDCAS,
AuthType_3270Host,*</param-value>
</init-param>
<init-param>
<param-name>CMPI_DCAS_KEYRING_FILE</param-name>
<param-value>C:\Program Files\IBM\HostOnDemand\HOD\HODDCAS.p12</param-value>
<description>An SSL key database file that contains the client and server
certificate information.</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_KEYRING_PASSWORD</param-name>
<param-value>45ie8WciVu=</param-value>
<description>Key database file password. Use the encrypt password tool.
</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_ADDRESS</param-name>
<param-value>jdbc:db2://bhttd.raleigh.ibm.com:6789/HODSSO</param-value>
<description>This is a URL string that provides the address
of the database.</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_TABLE</param-name>
<param-value>HACP</param-value>
<description>This entry identifies the table to use for the
needed query.</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_NET_DRIVER</param-name>
<param-value>COM.ibm.db2.jdbc.net.DB2Driver</param-value>
<description>This string contains the name of the class that will act
as the network database driver. The location of this class is assumed to
be in the existing classpath.</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_USERID</param-name>
<param-value>admin</param-value>
<description>This is the identification of the user account to use when
accessing the database.</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_PASSWORD</param-name>
<param-value>&*$^%&***</param-value>
<description>This is the password of the user account to use when
accessing the database.</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_NETID_COL_NAME</param-name>
<param-value>NETWORKID</param-value>
<description>Column name that contains the Network ID value</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_HOSTADDR_COL_NAME</param-name>
<param-value>HOSTADDRESS</param-value>
<description>Column name that contains host address value</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_HOSTAPP_COL_NAME</param-name>
<param-value>APPLICATIONID</param-value>
<description>Column name that contains host application value</description>
</init-param>
<init-param>
<param-name>CMPI_DCAS_DB_HOSTID_COL_NAME</param-name>
<param-value>HOSTID</param-value>
<description>Column name that contains host user ID value</description>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>CredMapper</servlet-name>
<url-pattern>/CredMapper</url-pattern>
</servlet-mapping>
</web-app>
Now that the administrator has edited the web.xml file, he repackages the WAR file using a zip tool.
AC Gas, Inc. uses WebSphere Application Server to deploy the CMS, which is made up of server-side Java classes that are deployed, managed, and executed on a J2EE-compliant application server. On a Windows platform, they take the following steps:
Since AC Gas, Inc. has a DCAS---based host, they need to create an SSL Key database using the Host On-Demand Certificate Management.
|
|
To create an SSL Key database on Windows and AIX platforms,
use the Host On-Demand Certificate Management. For other platforms, use a
P12 keyring tool. For more information, refer to the Planning, Installing,
and Configuring Host On-Demand guide, which is located in the Host On-Demand
InfoCenter at Start > Programs > IBM WebSphere Host On-Demand > InfoCenter
or on the Web at http://www.ibm.com/software/webservers/hostondemand/
library/v8infocenter/. |
In order to communicate with a DCAS server, an SSL connection must be established using client authentication. 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.
Company ABC creates a key database called HODDCAS.p12 file on a Windows machine by taking the following steps:
AC Gas, Inc. uses the steps listed in Step 4: Use the Deployment Wizard to create your HTML file. to create an HTML file using the Deployment Wizard. They choose the HTML-based configuration model.
Since AC Gas, Inc. has already installed Host On-Demand Version 8, they are ready to configure their session properties to use Web Express Logon. In the Deployment Wizard on the Host Sessions window, they highlight their 3270 session and select Properties under the Configure drop-down menu. On the left side of the window, they select Express Logon under Connection.
Once they select Yes to enable Express Logon, they type the full URL of the Credential Mapper Server, for example, https://server_name/junction/wel/CredMapper, where
The servlet that resides at this URL processes the HTTPS request from the user, performs a lookup, and returns the user's credentials. The Host On-Demand client uses the obtained credentials to automate the login process.
AC Gas, Inc. records their login macro using the steps in Step 6: Record the macro..
At this point, AC Gas, Inc. has implemented Web Express Logon, and its employees are able to access the host system without providing additional credentials.
The Credential Mapper Servlet (CMS) is the core of the credential-mapping framework and resides on a Web server and some Web application framework. At a high level, it has two primary roles: (1) request the client's credentials that are supplied by the network security application and (2) respond with the host access credentials. It accomplishes these tasks through credential mapper Java objects called plug-ins. Web Express Logon provides a CMS and two Network Security plug-ins (one for Tivoli Access Manager and one for Siteminder) to perform the request part of the process and two Host Credential plug-ins (one for DCAS and one for Vault) to perform the response part.
The Network Security plug-in retrieves the user's credentials from the network security application after the user has made an HTTPS request to the CMS. It identifies the user by way of the network user ID and password and then passes it on to the appropriate Host Credential plug-in. The Host Credential plug-in then determines the host user ID and acquires the host access credentials.
Depending on your environment, you can take one of two approaches for customizing the CMS. First, you may wish to replace the entire CMS with your own custom version of the servlet. In this case, you will need to use an HTTP parameter for requests and XML data for responses. Second, you may wish to use the existing CMS and integrate components using the APIs provided with Host On-Demand. This second approach requires less J2EE experience and is easier to implement.
|
|
Writing a custom CMS requires some J2EE knowledge and experience working with J2EE-compliant servlets. |
Parameters are supplied to the CMS servlet via an HTTP request. The response information is encapsulated into an XML-formatted object and returned to the caller.
When users first log on to their workstations or attempt to access some network resource, the network security application prompts them for their credentials. Once they are authenticated by the network security application, an HTTP request is made to the CMS using an HTTPS connection. Clients may make one or two requests to the CMS, depending on the model type of HTML page. The first request is sent to the CMS only if the HTML page was created using the Configuration server-based model. The second request is sent for sessions that are configured for macro-based automation. The Web server and application server listen for and receive the incoming request and pass it on to CMS for processing. Since it must be an HTTP request, the CMS request interface is built around a standard HTTPS query. Following the HTTPS protocol and server address is the query character, a question mark, and then a list of keys and values. These keys and values are separated by the ampersand symbol. Within each key and value pair, the key and value are separated by the symbol for equality. A sample query may look like the following example:
https://www.ibm.com/authserver/servlet/cms?operation=1 &destination=www.ibm.com/somehost&appid=tpf &authtype=AuthType_3270Host
Table 5 is a list of available keys:
| Key | Possible value |
operation |
'1' -- Credential Mapping Request |
destination |
This is the destination for which the credentials are being requested. |
appid |
This is the host application ID for which the credentials are being requested. |
authtype |
This is the type authentication credentials being requested (available authentication types are defined below). |
localid |
This optional value will supply the user's identification, based on the local operating system. For now, this solution supported only on the Windows operating system. |
The CMS returns its response to the client in XML format in an effort to make the response information structured and extensible. This XML format provides a good base for allowing structured access to the return data today and provide for expansion and improvement in the future. The following XML schema defines the format of the XML document:
<schema targetNamespace="" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="hod-sso-credential" type="hod-sso-credentialType" /> <complexType name="hod-sso-credentialType"> <sequence> <element name="userid" type="string" /> <element name="password" type="string" /> <element name="status" type="string" /> </sequence> <attribute name="version" type="string" /> </complexType> </schema>
Based on the above schema, the following code is a sample of the XML return document that is streamed over the HTTPS connection:
<?xml version="1.0"?> <hod-sso-credential version="1.0" > <userid>&^$#^&</userid> <password>&^$#^&</password> <status>0</status> </hod-sso-credential>
In the above code, the user ID and password elements return garbage characters because they are encrypted. Host On-Demand includes an object called com.ibm.com.eNetwork.HOD.common.PasswordCipher to accomplish this. It contains the following two methods:
The status element provides the status of the return value. If the credential mapper query fails for any reason, this field reports that failure to the client. Failure codes are defined in the SSOConstants class, which serves as a static repository of related SSO static information. Table 6 contains the status code definitions:
| Status code | Description |
| 0 | Success |
| 1 | Unknown status code |
| 2 | Credential Mapper not found |
| 3 | Invalid user ID |
| 4 | Invalid application ID |
| 5 | Invalid server address |
| 6 | Database connection error |
| 7 | User ID not found in database |
| 8 | Exception |
| 9 | Invalid user ID |
| 10 | Passticket error |
| 11 | Timeout |
| 12 | Unexpected DCAS return code |
| 13 | API not supported |
| 14 | Bad URL |
| 15 | Unable to parse response |
| 16 | Local user ID not available |
| 17 | Duplicate XML tags |
| 18 | An exception occurred while processing the credential request |
| 19 | Network Security plug-in is not defined to the CMS |
Describing how to create a servlet is not within the scope of this document, but there are resources available to help you, for example:
As discussed earlier, the CMS relies on plug-ins to provide the network user ID and host access credentials. The CMS interacts with these plug-ins via Java interfaces, which are described below.
All plug-ins must implement the following three Java interfaces:
The CMInterface interface contains the following methods:
The following methods are needed for plug-in identification and selection.
The CMRequest object is used by CMS to encapsulate all necessary parameters for a plug-in request. The following are its members and methods:
Members:
Methods
The CMResponse object encapulates all relevant information needed by the CMS for the request made of a plug-in. The following are its members and methods:
Members:
Methods:
Host On-Demand provides two Network Security plug-ins, one for Tivoli Access Manager and one for Netegrity Siteminder. If you decide not to use either of these, you may create your own plug-in.
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 from the incoming HTTP request object. The specifics of how to acquire the network ID is specific to your network security application. Refer to your network security documentation for more information.
Host On-Demand provides two Host Credential plug-ins, one for DCAS and one for Vault. If you decide not to use either of these, you may create your own plug-in.
The primary function of the Host Credential plug-in is to take the user's network ID (and perhaps the application ID) and obtain the appropriate host credentials. In Web Express Logon's implementation, users' network IDs are mapped to their host IDs during this process by way of a JDBC-accessible database. However, you may wish to do this by another means, such as LDAP. For this reason, you may want to write your own Host Credential plug-in. In our DCAS/JDBC plug-in, we automate z/OS logins by associating a users' network IDs to their host IDs, and taking the host ID with the application ID and obtaining a RACF-generated passticket. This passticket is then used to sign the user on to the host. In your environment, you may not want to use the JDBC association aspect of our plug-in. For this reason, we have provided our DCAS API. This API provides access to RACF--generated passtickets.
The DCAS API object (DCASClient) encapsulates the Passticket requests. Here are its members and methods:
Members:
Methods:
Web Express Logon depends on a number of independent processes working together to function properly. Some of these processes run on the Host On-Demand client while others run on other host systems. When one or more of these processes break down, you must be able to determine which process is causing the problem in order to resolve it appropriately. This portion of the document is devoted to that purpose.
If you have problems with Web Express Logon, analyze the type of results you receive and any accompanying informational messages. Some of these informational messages are included as part of the Host On-Demand client by way of an interactive panel, and/or they may be part of a server-based log.
Assuming that Web Express Logon is not functioning properly (that is, you are not logged in a host emulation session), ask yourself the following questions:
When an unexpected problem occurs during the Web Express Logon process, the Host On-Demand client provides information about the problem to the user by displaying a panel with an informational message. Each of these messages contain an error code that you can use as a unique identifier for the problem that is occurring. The following is a list of all Web Express Logon messages for the Host On-Demand client.
The following are the primary server-side messages:
<init-param>
<param-name>CMPICredentialMappers</param-name>
<param-value>vault</param-value>
</init-param>you would also need something like this,
<init-param>
<param-name>vault</param-name>
<param-value>com.ibm.eNetwork.security.sso.cms.CMPIVault,
AuthType_3270Host,*</param-value>
</init-param>or you would get the error above.
<init-param>
<param-name>CMPICredentialMappers</param-name>
<param-value>YourCredentialMapperName(s)</param-value>
</init-param>
<init-param>
<param-name>vault</param-name>
<param-value>com.ibm.eNetwork.security.sso.cms.CMPIVault,
AuthType_3270Host,*</param-value>
</init-param>this would show that the vault Credential Mapper
is only intended to be used with 3270 host sessions. If this were the only
Credential Mapper defined in your web.xml and you tried to perform a logon
to a 5250 session, you would receive this error with AuthTypeValue equal to
AuthType_5250Host. Be sure that your web.xml has a Credential Mapper defined
that is appropriate for your authentication type.
The following are the primary DCAS error messages:
Host On-Demand provides a password encryption tool so you can encrypt your passwords for added security. The tool is a command-line tool that allows you to generate a file that stores the encrypted password, which you must then copy to the appropriate place in the web.xml file. The Host Credential plug-in decrypts the password before using it.
If you create a custom Host Credential plug-in, the plug-in should use the com.ibm.eNetwork.HOD.common.PasswordCipher object to decrypt the password. The CLASS file for this object is included in WAR file. Refer to Custom Credential Mapper Servlet response object for a description of the encrypt and decrypt methods.
Using a DOS prompt, change the current directory to the Host On-Demand's bin directory and type the following command:
encrypt <password> [filename]
where password is the password to be encrypted and filename is the name of the file that you want to store the encrypted password. The default filename is password.txt.
Issue the following command:
cd your_install_dir
Java -classpath .;your_install_dir\lib\sm.zip \
com.ibm.eNetwork.security.sso.cms.tools.Encrypt <password> [filename]
where your_install_directory is your Host On-Demand installation directory, password is the password to be encrypted, and filename is the name of the file that you want to store the encrypted password. The default filename is password.txt.
The following terms are used throughout this document:
When editing Credential Mapper Servlet (CMS)-related parameters in the web.xml file for macro-based automation, the parameter value must contain the full class path name of the implementing class, the authentication type to be addressed by the credential mapper, and the host mask.
Once you specify the desired authentication type, the CMS can better identify which credential mapper to select to handle the request. You can pair multiple authentication types together to give Host Credential Mappers (HCM) the freedom to support multiple authentication types.
Connection-based automation works in iSeries environments that support Kerberos network authentication. With this type of automation, the user is authenticated through a telnet negotiation and the host never sends a login screen to authenticate the client. Therefore, connection-based automation does not require the use of a login macro, the Credential Mapper Servlet (CMS), a Network Security plug-in, nor the Host Credential Mapper (HCM).
Credential challenges are the time at which users are prompted to provide IDs and passwords.
For the macro-based automation style of Web Express Logon, the CMS is the core of the credential-mapping framework. It is supplied with Host On-Demand and must be deployed to a Web server or some type of Web application framework. At a high level, it has two primary roles: (1) request the client's credentials (called a network ID) and (2) respond with the host access credentials, which consist of the host ID and a password or passticket, depending on the type of HCM.
DCAS is a TCP/IP server that runs on z/OS and OS/390 platforms. TN3270 servers connect to DCAS using Secure Socket Layer (SSL). The purpose of DCAS is to receive an application ID and a digital certificate from a TN3270 server and then ask RACF to return a valid user ID that has been associated with the certificate and to generate a passticket for the input user ID and application ID.
EIM is an IBM eServer technology that helps you easily manage multiple user registries and user identities in an enterprise. EIM is an architecture for describing the relationships between individuals or entities (like file servers and print servers) in the enterprise and the many identities that represent them within an enterprise. In addition, EIM provides a set of APIs that allow applications to ask questions about these relationships.
When editing CMS-related parameters in the web.xml file for macro-based automation, the parameter value must contain the full class path name of the implementing class, the authentication type to be addressed by the credential mapper, and the host mask.
The CMS uses the value of the full class path name to create a class object of the specified type. That object is then used to handle CMS network security or HCM queries. You must place the specified class file in the ...\WEB-INF\classes subdirectory in a loose file (not as a JAR file). From this location, the CMS will be able to access and use it whenever the need arises.
The HCM 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 DCAS and Vault plug-ins provided with Web Express Logon are designed to work with a such a database. Another possibility for a repository is an LDAP directory. However, using LDAP as your HCM requires you to write your own plug-in..
A host ID is the credential used to uniquely identify the user to the host being accessed. In macro-based automation, the host ID is what the Host Credential Mapper returns to the Credential Mapper servlet in order to achieve single sign-on.
When editing CMS-related parameters in the web.xml file for macro-based automation, the parameter value must contain the full class path name of the implementing class, the authentication type to be addressed by the credential mapper, and the host mask.
The host mask is a secondary selection criteria used by the CMS to identify the most appropriate credential mapper. This value can contain one or more host addresses.
Kerberos is a network authentication protocol that identifies and authenticates users who request to log on to a network. It provides a means of verifying the identities of principals (users) on physically insecure networks. It provides mutual authentication, data integrity, and privacy under the realistic assumption that network traffic is vulnerable to capture, examination, and substitution.
Macro-based automation is for environments of varying host types that are not using Kerberos authentication. As the name implies, it requires you to create a macro to perform logon automation.
In order to use the macro-based automation style of Web Express Logon, you must have a network security application in place. Host On-Demand provides out-of-the-box support for three common network security applications without requiring additional coding: IBM Tivoli Access Manager, Netegrity Siteminder, and Microsoft Active Directory (Windows Domain). If you have a different network security application, you will need to create your own plug-in to work in your environment.
A network ID is the credential that uniquely identifies the user to the network security application. In macro-based automation, the CMS calls upon the Network Security plug-in to acquire the user's network ID from the network security application.
In macro-based automation, the Network Security plug-in acquires the user's network ID from the network security application.
RACF is an IBM security product that protects resources by granting access to only authorized users of protected resources. RACF retains information about the users, resources, and access authorities in profiles on the RACF database and refers to the profiles when deciding which users should be permitted access to protected system resources.
Use the following sources to help you implement Web Express Logon in your environment:
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or region or send inquiries, in writing, to:
IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or any other country or region where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation Department T01 Building B062 P.O. Box 12195 Research Triangle Park, NC 27709-2195 U.S.A.
Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.
Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
If you are viewing this information softcopy, the photographs and color illustrations may not appear.
The following terms are trademarks of International Business Machines Corporation in the United States, other countries, or both: IBM
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Microsoft, Windows, Windows NT, and the Windows logo are registered trademarks of Microsoft Corporation.
Other company, product, and service names may be trademarks or service marks of others.