settings

To specify the features that a server supports when acting as a client to another downstream server.

  1. Click...

      Security | Global security

  2. From Authentication, click RMI/IIOP security > CSIv2 outbound communications.

Authentication features include three layers of authentication that we can use simultaneously:

Propagate security attributes

Specifies to support security attribute propagation during login requests. When you select this option, the appserver retains additional information about the login request, such as the authentication strength used, and retains the identity and location of the request originator.

If we do not select this option, the appserver does not accept any additional login information to propagate to downstream servers.

Default: Enabled

When you use the replication services, ensure that the Propagate security attributes option is enabled.

Use server-trusted identity

Server identity that the appserver uses to establish trust with the target server. The server identity can be sent using one of the following methods:

  • A server ID and password when the server password is specified in the registry configuration.

  • A server ID in a LTPA token when the internal server ID is used.

For interoperability with appservers other than WAS, use one of the following methods:

  • Set the server ID and password in the registry.

  • Select the Server-trusted identity option and specify the trusted identity and password so that an interoperable Generic Security Services Username (GSSUP) token is sent instead of an LTPA token.

Default: Disabled

Specify an alternative trusted identity

Specifies an alternative user as the trusted identity that is sent to the target servers instead of sending the server identity.

This option is recommended for identity assertion. The identity is automatically trusted when it is sent within the same cell and does not need to be in the trusted identities list within the same cell. However, this identity must be in the registry of the target servers in an external cell, and the user ID must be on the trusted identities list or the identity is rejected during trust evaluation.

Default: Disabled

Trusted identity

Trusted identity that is sent from the sending server to the receiving server.

If we specify an identity in this field, it can be selected on the panel for the configured user account repository. If we do not specify an identity, a LTPA token is sent between the servers.

Specifies a pipe-separated (|) list of trusted server administrator user IDs, which are trusted to perform identity assertion to this server. For example, serverid1|serverid2|serverid3. The appserver supports the comma (,) character as the list delimiter for backwards compatibility. The appserver checks the comma character when the pipe character (|) fails to find a valid trusted server ID.

Use this list to decide whether a server is trusted. Even if the server is on the list, the sending server must still authenticate with the receiving server to accept the identity token of the sending server.

that is associated with the trusted identity.

Data type: Text

Confirm password

Confirms the password that is associated with the trusted identity.

Data type: Text

Message layer authentication

The following options are available for message layer authentication:

Never

This server cannot accept user ID and password authentication.

Supported

A client communicating with this server can specify a user ID and password. However, a method might be invoked without this type of authentication. For example, an anonymous or client certificate might be used instead.

Required

Specifies that clients communicating with this server must specify a user ID and password for any method request.

Allow client to server authentication with:

Specifies client-to-server authentication using Kerberos, LTPA or Basic authentication.

The following options are available for client to server authentication:

Kerberos (KRB5)

Select to specify Kerberos as the authentication mechanism. You must first configure the Kerberos authentication mechanism. Read about Set Kerberos as the authentication mechanism for more information.

LTPA

Select to configure and enable Lightweight Third-Party Authentication (LTPA) token authentication.

Basic authentication

Basic authentication is Generic Security Services Username (GSSUP). This type of authentication typically involves sending a user ID and a password from the client to the server for authentication.

If we select Basic Authentication and LTPA, and the active authentication mechanism is LTPA, the server goes with a downstream server with a user name, password or LTPA token.

If we select Basic Authentication and KRB5, and the active authentication mechanism is KRB5, the server goes with a downstream server with a user name, password, Kerberos token or LTPA token.

If we do not select Basic Authentication, the server does not go with a downstream server with a user name and password.

Transport

Whether client processes connect to the server using one of its connected transports.

We can choose to use either SSL, TCP/IP or both as the inbound transport that a server supports. If we specify TCP/IP, the server only supports TCP/IP and cannot accept SSL connections. If we specify SSL-supported, this server can support either TCP/IP or SSL connections. If we specify SSL-required, then any server communicating with this one must use SSL.

This option is not available on the z/OS operating system unless both V6.0.x and earlier nodes exist in the cell.

TCP/IP

If we select TCP/IP, then the server opens a TCP/IP listener port only and all inbound requests do not have SSL protection.

SSL-required

If we select SSL-required, then the server opens an SSL listener port only and all inbound requests are received using SSL.

SSL-supported

If we select SSL-supported, then the server opens both a TCP/IP and an SSL listener port and most inbound requests are received using SSL.

Provide a fixed port number for the following ports. A zero port number indicates that a dynamic assignment is made at run time.

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS

Default: SSL-Supported
Range: TCP/IP, SSL Required, SSL-Supported

SSL settings

List of predefined SSL settings to choose from for inbound connection.

Data type: String
Default: DefaultSSLSettings
DefaultIIOPSSL
Range: Any SSL settings configured in the SSL Configuration Repertoire

Client certificate authentication

Whether a client certificate from the configured keystore is used to authenticate to the server when the SSL connection is made between this server and a downstream server, provided that the downstream server supports client certificate authentication.

Typically, client certificate authentication has a higher performance than message layer authentication, but requires some additional setup. These additional steps include verifying that this server has a personal certificate and that the downstream server has the signer certificate of this server.

If we select client certificate authentication, the following options are available:

Never

This server does not attempt SSL client certificate authentication with downstream servers.

Supported

This server can use SSL client certificates to authenticate to downstream servers. However, a method can be invoked without this type of authentication. For example, the server can use anonymous or basic authentication instead.

Required

This server must use SSL client certificates to authenticate to downstream servers.

Default: Enabled

Login configuration

Type of system login configuration to use for inbound authentication.

We can add custom login modules by clicking Security > Global security. From Authentication, click Java Authentication and Authorization Service > System logins.

Stateful sessions

Select this option to enable stateful sessions, which are used mostly for performance improvements.

The first contact between a client and server must fully authenticate. However, all subsequent contacts with valid sessions reuse the security information. The client passes a context ID to the server, and the ID is used to look up the session. The context ID is scoped to the connection, which guarantees uniqueness. Whenever the security session is not valid and the authentication retry is enabled, which is the default, the client-side security interceptor invalidates the client-side session and submits the request again without user awareness. This situation might occur if the session does not exist on the server, for example, the server failed and resumed operation. When this value is disabled, every method invocation must authenticate again.

Custom outbound mapping

Enables the use of custom RMI outbound login modules.

The custom login module maps or completes other functions before the predefined RMI outbound call.

To declare a custom outbound mapping...

  1. Click...

      Security | Global security

  2. From Authentication, click Java Authentication and Authorization Service > System logins > New.

Trusted authentication realms - outbound

If the RMI/IIOP communication is across different realms, use this link to add outbound trusted realms.

The credential tokens are only sent to the realms that are trusted. In addition, the receiving server should trust this realm using the inbound trusted realms configuration to validate the LTPA token.





 

Related tasks


Set CSIv2 outbound communications