By using this configuration, you can configure a different
transport for inbound security versus outbound security.
Before you begin
Inbound
transports refer to the types of listener ports and their attributes
that are opened to receive requests for this server. Both Common Secure
Interoperability Specification, Version 2 (CSIv2) and Secure Authentication
Service (SAS) have the ability to configure the transport.
Inbound
transports refer to the types of listener ports and their attributes
that are opened to receive requests for this server. Both Common Secure
Interoperability Specification, Version 2 (CSIv2) and Secure Authentication
Service (SAS) have the ability to configure the transport.
Inbound transports refer
to the types of listener ports and their attributes that are opened
to receive requests for this server. Both Common Secure Interoperability
Specification, Version 2 (CSIv2) and z/OS Secure Authentication Service
(z/SAS) have the ability to configure the transport.
Inbound
transports refer to the types of listener ports and their attributes
that are opened to receive requests for this server. Both Common Secure
Interoperability Specification, Version 2 (CSIv2) and z/OS Secure
Authentication Service (z/SAS) have the ability to configure the transport.
![[AIX HP-UX Linux Solaris Windows]](../../dist.gif)
However,
the following differences between the two protocols exist:
- CSIv2 is much more flexible than SAS, which requires Secure Sockets
Layer (SSL); CSIv2 does not require SSL.
- SAS does not support SSL client certificate authentication, while
CSIv2 does.
- CSIv2 can require SSL connections, while SAS supports only SSL
connections.
- SAS always has two listener ports open: TCP/IP and SSL.
- CSIv2 can have as few as one listener port and as many as three
listener ports. You can open one port for just TCP/IP or when SSL
is required. You can open two ports when SSL is supported, and open
three ports when SSL and SSL client certificate authentication is
supported.
- CSIv2 is much more flexible than SAS, which requires Secure Sockets
Layer (SSL); CSIv2 does not require SSL.
- SAS does not support SSL client certificate authentication, while
CSIv2 does.
- CSIv2 can require SSL connections, while SAS only supports SSL
connections.
- SAS always has two listener ports open: TCP/IP and SSL.
- CSIv2 can have as few as one listener port and as many as three
listener ports. You can open one port for just TCP/IP or when SSL
is required. You can open two ports when SSL is supported, and open
three ports when SSL and SSL client certificate authentication is
supported.
CSIv2
and z/SAS support most of the same functions. CSIv2 has the advantage
of interoperability with other WebSphere Application Server products
and any other platforms that support the CSIv2 protocol.
CSIv2
and z/SAS support most of the same functions. CSIv2 has the advantage
of interoperability with other WebSphere Application Server products
and any other platforms that support the CSIv2 protocol.
About this task
Complete the following steps to configure the Inbound transport
panels in the administrative console:
Procedure
- Click Security > Global security.
- Under Authentication, click Authentication
Protocol > CSIv2 inbound transport to select the type of transport
and the SSL settings. By selecting the type of transport,
as noted previously, you choose which listener ports you want to open.
In addition, you disable the SSL client certificate authentication
feature if you choose TCP/IP as the transport.
- Select the SSL settings that correspond
to an SSL transport. These SSL settings are defined in
the Security > SSL panel and define the SSL configuration
including the key ring, security level, ciphers, and so on.
- Click Apply in the CSIv2 inbound transport panel.
- Consider fixing the listener ports that you
configured.
For an application server, click Servers > Application
servers > server_name. Under Communications, click Ports.
The Ports panel is displayed for the specified server.
For a
node agent, go to System administration > Node agents > node_name.
Under Additional properties, click Ports. The Ports panel for
the node agent and deployment manager already are fixed, but you might
consider reassigning the ports. For the deployment manager, click System
Administration > Deployment manager. Under Additional properties,
click Ports.
The Object Request Broker (ORB) on WebSphere
Application Server uses a listener port for Remote Method Invocation
over the Internet Inter-ORB Protocol (RMI/IIOP) communications, and
is statically specified using configuration dialogs or during migration. The ORB_LISTENER_ADDRESS
and the BOOTSTRAP_ADDRESS must specify the same port. If you
are working with a firewall, you must specify a static port for the
ORB listener and open that port on the firewall so that communication
can pass through the specified port. The endPoint property for setting
the ORB listener port is: ORB_LISTENER_ADDRESS.
![[AIX HP-UX Linux Solaris Windows]](../../dist.gif)
In the
WebSphere Application Server Network Deployment environment, the ORB_LISTENER_ADDRESS
end point is specified on the node agent. The location service daemon
resides on the node agent and piggybacks onto the ORB listener port,
which results in needing the port fixed. Also, you must add the ORB_LISTENER_ADDRESS
to the other application servers to set their ORB listener port. Each
ORB has a distinct listener port. In WebSphere Application Server
Network Deployment, you must specify a different listener port. For
example, you might specify the following ports:
- Node agent: ORB_LISTENER_ADDRESS=9000
- Server1: ORB_LISTENER_ADDRESS=9811
- Server2: ORB_LISTENER_ADDRESS=9812
![[AIX HP-UX Linux Solaris Windows]](../../dist.gif)
Federated
servers can run without the node agent running. When ORB_LISTENER_ADDRESS
is set to a value of zero (0) or greater, the server does not depend
on the location service daemon to redirect connections to the server.
When you set ORB_LISTENER_ADDRESS, all object references in the namespace
specify the connection to the server, not the location service daemon.
When the server is running without the node agent, all applications
must be accessed through the name server that runs on the application
server. The client must change the Java Naming Directory Interface
(JNDI) reference to use the host and port of the application server.
Table 1.
ORB_LISTENER_ADDRESS |
|
value = 0 |
The server starts
on any available port and does not use the location service daemon. |
value > 0 |
The server starts
on the port that is specified by the value you enter. The location
service daemon is not used. |
Note: Work load management might not work without the node
agent running.
Complete the following steps
using the administrative console to specify the ORB_LISTENER_ADDRESS
port or ports.
Complete
the following steps for the node agent and the deployment manager.
- Click Servers > Application Servers > server_name.
Under Communications, click Ports > New.
- Select ORB_LISTENER_ADDRESS from the Port
name field in the Configuration panel.
Enter the IP address, the fully
qualified Domain Name System (DNS) host name, or the DNS host name
by itself in the Host field. For example, if the
host name is myhost, the fully qualified DNS name can be myhost.myco.com and
the IP address can be 155.123.88.201.
Enter the IP address or "*" in the Host field.
For example the IP address can be 155.123.88.201. Important: DNS host names are not supported for the ORB_LISTENER_ADDRESS
value.
- Enter the port number in the Port field.
The port number specifies the port for which the service is
configured to accept client requests. The port value is used with
the host name. Using the previous example, the port number might be
9000.
Click Security > Global security. Under Authentication,
click Authentication protocol > CSIv2 inbound transport to
select the SSL settings that are used for inbound requests from CSIv2
clients. Remember that the CSIv2 protocol is used to inter-operate
with previous releases. When configuring the keystore and truststore
files in the SSL configuration, these files need the right information
for inter-operating with previous releases of WebSphere Application
Server. For example, a previous release has a different truststore
file than the Version 6 release. If you use the Version 6 keystore
file, add the signer to the truststore file of the previous release
for those clients connecting to this server.
Click Security
> Global security. Under Authentication, click Authentication
protocol > SAS authentication to select the SSL settings used
for inbound requests from z/SAS clients.
Click Security
> Secure administration, applications, and infrastructure. Under
RMI/IIOP security, click z/SAS authentication to select the
SSL settings used for inbound requests from z/SAS clients.
Results
The inbound transport configuration is complete. With this
configuration, you can configure a different transport for inbound
security versus outbound security. For example, if the application
server is the first server that is used by users, the security configuration
might be more secure. When requests go to back-end enterprise bean
servers, you might lessen the security for performance reasons when
you go outbound. With this flexibility you can design the right transport
infrastructure to meet your needs.
What to do next
When you finish configuring security, perform the following
steps to save, synchronize, and restart the servers:
- Click Save in the administrative console to save any modifications
to the configuration.
Synchronize
the configuration with all node agents.
- Stop and restart all servers, when synchronized.