CSIv2 outbound communications settings

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

To view this administrative console page:

1. Click Security > Global security.

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

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

• CSIv2 attribute layer. The attribute layer might contain an identity token, which is an identity from an upstream server that already is authenticated. The identity layer has the highest priority, followed by the message layer, and then the transport layer. If a client sends all three, only the identity layer is used. The only way to use the SSL client certificate as the identity is if it is the only information that is presented during the request. The client picks up the interoperable object reference (IOR) from the namespace and reads the values from the tagged component to determine what the server needs for security.
• CSIv2 transport layer. The transport layer, which is the lowest layer, might contain an SSL client certificate as the identity.

• (iSeries) (Dist) CSIv2 message layer. The message layer might contain a user ID and password or an authenticated token with an expiration.

Propagate security attributes

To support security attribute propagation during login requests. When selected, the application server retains additional information about the login request, such as the authentication strength used, and retains the identity and location of the request originator.

If not selected, the application server does not accept any additional login information to propagate to downstream servers.

Information	Value
Default:	Enabled

Important: When we use the replication services, ensure that the Propagate security attributes option is enabled.

Use identity assertion

That identity assertion is a way to assert identities from one server to another during a downstream EJB invocation.

This server does not authenticate the asserted identity again because it trusts the upstream server. Identity assertion takes precedence over all other types of authentication.

Identity assertion is performed in the attribute layer and is only applicable on servers. The principal determined at the server is based on precedence rules. If identity assertion is performed, the identity is always derived from the attribute layer. If basic authentication is used without identity assertion, the identity is always derived from the message layer. Finally, if SSL client certificate authentication is performed without either basic authentication, or identity assertion, then the identity is derived from the transport layer.

The identity asserted is the invocation credential determined by the RunAs mode for the enterprise bean. If the RunAs mode is Client, the identity is the client identity. If the RunAs mode is System, the identity is the server identity. If the RunAs mode is Specified, the identity is the one specified. The receiving server receives the identity in an identity token and also receives the sending server identity in a client authentication token. The receiving server validates the sending server identity as a trusted identity through the Trusted Server IDs entry box. Enter a list of pipe-separated (|) principal names, for example, serverid1|serverid2|serverid3.

All identity token types map to the user ID field of the active user registry. For an ITTPrincipal identity token, this token maps one-to-one with the user ID fields. For an ITTDistinguishedName identity token, the value from the first equal sign is mapped to the user ID field. For an ITTCertChain identity token, the value from the first equal sign of the distinguished name is mapped to the user ID field.

When authenticating to an LDAP user registry, the LDAP filters determine how an identity of type ITTCertChain and ITTDistinguishedName get mapped to the registry. If the token type is ITTPrincipal, then the principal gets mapped to the UID field in the LDAP registry.

Information	Value
Default:	Disabled

Use server-trusted identity

Server identity that the application server 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 application servers other than WebSphere Application Server, use one of the following methods:

• Configure the server ID and password in the registry.

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

Information	Value
Default:	Disabled

Specify an alternative trusted identity

Specifies an alternative user as the trusted identity 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.

We must select Basic Authentication under the Message Layer authentication section to send an alternative trusted identity. If we do not select Basic Authentication, then choose the Server Identity instead.

Information	Value
Default:	Disabled

Trusted identity

Trusted identity 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 our configured user account repository. If we do not specify an identity, a LPTA token is sent between the servers.

(ZOS) Specifies a semicolon-separated (;) or comma-separated (,) list of trusted server IDs, which are trusted to perform identity assertion to this server. For example, serverid1;serverid2;serverid3 or serverid1,serverid2,serverid3.

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.

Password

Password associated with the trusted identity.

Information	Value
Data type:	Text

Confirm password

Confirms the password associated with the trusted identity.

Information	Value
Data type:	Text

Message layer authentication

The following options are available for message layer authentication:

Never

This server cannot accept authentication using any of the mechanisms selected.

Supported

A client communicating with this server can authenticate using any of the mechanisms selected. However, a method might be invoked without this type of authentication. For example, an anonymous or client certificate might be used instead.

Required

Clients communicating with this server must specify authentication information using of the mechanisms selected 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. We must first configure the Kerberos authentication mechanism. Read about Configure Kerberos as the authentication mechanism for more information.

LTPA

Select to configure and enable LTPA token authentication.

Basic authentication

Basic authentication is Generic Security Services Username Password (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

Specifies whether the client processes connect to the server using one of the server-connected transports.

We can choose to use either SSL, TCP/IP, or Both as the outbound transport that a server supports. If we specify TCP/IP, the server supports only TCP/IP and cannot initiate SSL connections with downstream servers. If we specify SSL-supported, this server can initiate either TCP/IP or SSL connections. If we specify SSL-required, this server must use SSL to initiate connections to downstream servers. When we do specify SSL, decide which set of SSL configuration settings we want to use for the outbound configuration.

This decision determines which keyfile and trustfile to use for outbound connections to downstream servers.

Consider the following options:

TCP/IP

If we select this option, the server opens TCP/IP connections with downstream servers only.

SSL-required

If we select this option, the server opens SSL connections with downstream servers.

SSL-supported

If we select this option, the server opens SSL connections with any downstream server that supports them and opens TCP/IP connections with any downstream servers that do not support SSL.

Information	Value
Default:	SSL-supported
Range:	TCP/IP, SSL-required, SSL-supported

SSL settings

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

Information	Value
Data type:	String
Default:	DefaultSSLSettings
(ZOS) Default:	DefaultIIOPSSL
Range:	Any SSL settings configured in the SSL Configuration Repertoire

Client certificate authentication

Specifies 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

That 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

That this server must use SSL client certificates to authenticate to downstream servers.

Information	Value
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 JAAS > 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, the session was deleted from the session cache, or the session was established with another member of the cluster. When this value is disabled, every method invocation must authenticate again.

If there are excessive NO_PERMISSION errors with the SessionDoesNotExist (49424308 in hex) minor code, then consider updating the session cache limit or the idle session timeout values.

Enable CSIv2 session cache limit

Specifies whether to limit the size of the CSIv2 session cache.

When we enable this option, we must set values for the Maximum cache size and Idle session timeout options. When we do not enable this option, the CSIv2 session cache is not limited.

In previous versions of the application server, we might have set this value as the com.ibm.websphere.security.util.csiv2SessionCacheLimitEnabled custom property. In this product version, it is advisable to set this value using this administrative console panel and not as a custom property.

Information	Value
Default:	false

Maximum cache size

Specify the maximum size of the session cache after which expired sessions are deleted from the cache.

Expired sessions are defined as sessions that are idle longer than the time specified in the Idle session timeout field. When we specify a value for the Maximum cache size field, consider setting its value between 100 and 1000 entries.

Consider specifying a value for this field if the environment uses Kerberos authentication and has a short clock skew for the configured key distribution center (KDC). In this scenario, a short clock skew is defined as less than 20 minutes. Consider increasing the value of this field if the small cache size causes the garbage collection to run so frequently that it impacts the performance of the application server.

In previous versions of the application server, we might have set this value as the com.ibm.websphere.security.util.csiv2SessionCacheMaxSize custom property. In this product version, it is advisable to set this value using this administrative console panel and not as a custom property.

This field only applies if we enable both the Stateful sessions and the Enable CSIv2 session cache limit options.

Information	Value
Default:	By default, a value is not set.
Range:	100 to 1000 entries

Idle session timeout

Time in milliseconds that a CSIv2 session can remain idle before being deleted. The session is deleted if we select the Enable CSIv2 session cache limit option and the value of the Maximum cache size field is exceeded.

This timeout value only applies if we enable both the Stateful sessions and the Enable CSIv2 session cache limit options. Consider decreasing the value for this field if the environment uses Kerberos authentication and has a short clock skew for the configured key distribution center (KDC). In this scenario, a short clock skew is defined as less than 20 minutes. A small clock skew can result in a larger number of rejected CSIv2 sessions. However, with a smaller value for the Idle session timeout field, the application server can clean out these rejected sessions more frequently and potentially reduce the resource shortages.

In previous versions of WAS, we might have set this value as the com.ibm.websphere.security.util.csiv2SessionCacheIdleTime custom property. In this product version, it is advisable to set this value using this administrative console panel and not as a custom property. If we previously set it as a custom property, the value was set in milliseconds and converted on this administrative console panel to seconds. On this administrative console panel, specify the value in seconds.

Information	Value
Default:	By default, a value is not set.
Range:	60 to 86,400 seconds

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 JAAS > 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.

Configure CSIv2 outbound communications