Host Integration Server provides security at many
levels required to support the split stack architecture and connectivity
against the legacy system. From a user-level access standpoint, it is
through the common settings, shown in Figure 1,
where you have to define the groups named HIS Runtime Group and Host
Integration Server Administrators. The HIS Administrators group should
be used for the operations team, whereas the HIS Runtime Group should
contain the client application users (including Host Integration Server
service accounts). If you have a client application like a .NET web
application, you have to add your web application pool identity user as a
member of the Host Integration Server runtime users group.
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.
To be in line with the Attachsec parameter of the CICS CONNECTION
definition, you should select the "Use already verified or persistent
verification authentication" option. So, what if you are not using
Enterprise SSO at all? Then you can still pass credentials from your
Transaction Integrator client application using the "Require client
provided security" option and using the ClientContext object from your custom code. You will have to pass the credentials using the USERID and PASSWORD
properties of the referred object. The client context has been updated
in Host Integration Server 2009 to support dynamic remote environments
while maintaining backward compatibility. With Host Integration Server
2009, a user no longer needs to specify Include Context Parameter on a
method in the Transaction Integrator library. The user still has the
ability to not allow the client context; it's just included by default
now.