BizTalk 2009 : Host Integration Server 2009 - Security

Figure 1. Host Integration Server 2009 Common Settings configuration

Once you have created the user groups, you have to define service accounts for every Host Integration Server service. If you are wondering how to manage password expirations with the Host Integration Server service accounts, you can use the Host Integration Server configuration tool to do an unattended update of the service account password.

From an SNA configuration perspective, the COM.cfg file, which contains all the configuration information for the gateway, is located in a locked-down directory, and only a service account or an account belonging to one of the Host Integration Server groups can perform changes onto it. It is also shared as COMCFG$.

From a network perspective, the discussion is different. The ports required by a Host Integration Server client, or a Transaction Integrator nodeless server to get connected against a Host Integration Server, are 1477 (SnaServerPort) and 1478 (SnaBase-Datagram). Port 1477 is used for application connectivity (SNA application), and port 1478 is used for the sponsor and broadcast connections. Remember that when using Named Pipes, port 139 is also used. To change the default port from 1478 to something else, you can add the SnaBasePort and TargetServerSnaBasePort entries to the registry key System\CurrentControlSet\Services\SnaBase\Parameters\SnaTcp\ in the server and client, respectively, with the new value.

To change the default SnaServerPort port 1477 to a different number, you can add the SnaServerPort entry with the new value in the same registry key.

Now, for the IP-DLC Link Service, we strongly recommend using IPSec in cases where connectivity implies external components. Although there are customers who use SNA session-level encryption, Host Integration Server doesn't support SNA session-level encryption.

The mainframe handles security in different ways. The most common security schema provided by the mainframe is the IBM Resource Access Control Facility (RACF). RACF provides access control for the z/OS. One important consideration when working with mainframes is that when using the CICS link programming model, IBM DPL doesn't transfer the Windows credentials to the CICS application. On top of this, the CICS application assumes that the validation has taken place already and will use the default CICS application's account. If you want to change this behavior, you will need to change the ATtachsec parameter in the CEDA CONNECTION definition to reflect any of the following values:

LOCAL: This setting does not require SSO, and it provides no authentication. You can use LOCAL if you do not want to use authentication. Your client may consider that the authority of the link is enough for the Transaction Integrator system.

Non-LOCAL: This setting should be used if you require the users to be authenticated by requiring a user ID, or a user ID and a password, to be sent. Non-LOCAL includes the following types of validations:

• IDENTIFY: A user ID must be sent, but no password is requested.

• VERIFY: A password must be sent.

• PERSISTENT VERIFICATION: A password is sent on the first attach request for a specific user.

• MIXIDPE: It represents either identify or persistent verification.

From an application standpoint, Enterprise Single Sign-On (Enterprise SSO) should be deployed in the Windows environment to allow credentials mapping between the mainframe and Host Integration Server. To deploy it, you need to install Enterprise SSO from the Host Integration Server or BizTalk Server's Setup program. Once you have installed Enterprise SSO, you will need to create an affiliate application that will represent the mainframe application and that will store Windows and mainframe credentials for the applications you are targeting to use. We recommend you deploy the Enterprise SSO in a clustered environment, if possible, so you add high availability to the solution.

Once Enterprise SSO is deployed and the mainframe security mechanism has been defined and/or the security credentials are known, you need to assign an Enterprise Single Sign-On "Affiliated Application" in the SNA Manager and Transaction Integrator. In the SNA Manager, you can do this inside your IP-DLC connection properties window. There is a dropdown list where you can select Affiliated Application so the security will be applied at the connectivity level. In the Transaction Integrator, you can set an affiliate application on the Security tab of the remote environment properties window.

When selecting the Enable Single Sign-On option, shown in Figure 2, there are also a few more options available: User Credentials and the COM+ Application Credentials. You should select the first if the user credentials can be captured from the Transaction Integrator runtime. You should select the latter whenever you will allow Transaction Integrator to capture the credentials information as defined for a COM+ application. If you plan to control the pass of credentials from code, even though you are using Enterprise SSO, then you should select the "Allow application to override selected authentication" option.

Figure 2. Security properties window in Transaction Integrator remote environment definition