+

Search Tips   |   Advanced Search

CSIv2 inbound communications settings

Use this page to specify the features that a server supports for a client accessing its resources.

To view this administrative console page:

  1. Click Security > Global security.

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

Use common secure interoperability (CSI) inbound communications settings for configuring the type of authentication information contained in an incoming request or transport.

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


Propagate security attributes

Specifies support for security attribute propagation during login requests. When you select this option, 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 we do not select this option, the application server does not accept any additional login information to propagate to downstream servers.

Information Value
Default: Enabled

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


Use identity assertion

Specifies 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 used, 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 that is 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

(zos) The following option is enabled when the active user registry is a Local OS user registry, the z/OS security version is at the appropriate version that supports the distributed identity mapping, and there are no nodes prior to WebSphere Application Server Version 8.0:

Map certificate and DN using SAF distributed identity mapping

Select this option maps an asserted certificate and distinguished name to an SAF user identity using an RACMAP filter.

The default value is unchecked. When checked, the security custom property, com.ibm.websphere.security.certdn.useRACMAPMappingToSAF, is set to true.

This option is only visible when the active user registry is Local OS, the cell is not mixed-version (no nodes prior to WebSphere Application Server Version 8.0), and the z/OS security product supports SAF identity mapping (for RACF , this means z/OS version 1.11 or later).

If the DN name has a blank space between the attributes, then you should apply the RACF APAR OA34258, or PTF UA59873, and the SAF APAR OA34259, or PTF UA59871, to correctly parse the blanks.


Trusted identities

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

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 application server supports the comma (,) character as the list delimiter for backwards compatibility. The application server 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.

Information Value
Data type: String


Client certificate authentication

Specifies that authentication occurs when the initial connection is made between the client and the server during a method request.

In the transport layer, SSL client certificate authentication occurs. In the message layer, basic authentication (user ID and password) is used. Client certificate authentication typically performs better than message layer authentication, but requires some additional setup. These additional steps involve verifying that the server trusts the signer certificate of each client to which it is connected. If the client uses a certificate authority (CA) to create its personal certificate, we only need the CA root certificate in the server signer section of the SSL trust file.

When the certificate is authenticated to a LDAP user registry, the distinguished name (DN) is mapped based on the filter specified when configuring LDAP. When the certificate is authenticated to a local OS user registry, the first attribute of the distinguished name (DN) in the certificate, which is typically the common name, is mapped to the user ID in the registry.

(zos) When the certificate is authenticated to a local OS user registry, the certificate is mapped to the user ID in the registry.

The identity from client certificates is used only if no other layer of authentication is presented to the server.

Never

Specifies that clients cannot attempt SSL client certificate authentication with this server.

Supported

Specifies that clients connecting to this server can authenticate using SSL client certificates. However, the server can invoke a method without this type of authentication. For example, anonymous or basic authentication can be used instead.

(zos) Note: When "Supported" is set for CSIv2 Inbound authentication on the server, the client certificate is used for the authentication.

Required

Specifies that clients connecting to this server must authenticate using SSL client certificates before invoking the method.

(zos) The following option is enabled when the active user registry is a Local OS user registry, the z/OS security version is at the appropriate version that supports the distributed identity mapping, and there are no nodes prior to WebSphere Application Server Version 8.0:

Map certificate using SAF distributed identity mapping

Select this option maps a certificate received in the CSIv2 transport layer to an SAF user identity using an RACMAP filter.

The default value is unchecked. When checked, the security custom property, com.ibm.websphere.security.certificate.useRACMAPMappingToSAF, is set to true.

This option is only visible when the active user registry is Local OS, the cell is not mixed-version (no nodes prior to WebSphere Application Server Version 8.0), and the z/OS security product supports SAF identity mapping (for RACF, this means z/OS version 1.11 or later).


Transport

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

We can choose 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 platform unless both Version 6.1 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.
(dist)(iseries)

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS
(zos)

ORB_SSL_LISTENER_ADDRESS

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


SSL settings

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

(zos) Note: This option is not available on the z/OS platform unless both Version 6.1 and earlier nodes exist in the cell.

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


Message layer authentication

The following options are available for message layer authentication:

Never

Specifies that this server cannot accept authentication using any of the following mechanisms selected.

Supported

Specifies that a client communicating with this server can authenticate using any of the following 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

Specifies that clients communicating with this server must specify authentication information using of the following 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 using the administrative console for more information.

LTPA

Select to specify the 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, a user name, password, and LTPA tokens are accepted.

If we select Basic Authentication and KRB5 and the active authentication mechanism is KRB5, a user name, password, Kerberos token and LTPA tokens are accepted.

If we do not select Basic Authentication, a user name and password are not accepted by the server.


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, 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, each method invocation must authenticate again.

Information Value
Default: Enabled


Trusted authentication realms - inbound

Select this link to establish inbound trust for realms. Inbound authentication realm settings are not specific to CSIv2; we can also configure which realms to grant inbound trust to for multiple security domains.

Inbound authentication refers to the configuration that determines the type of accepted authentication for inbound requests. This authentication is advertised in the interoperable object reference (IOR) that the client retrieves from the name server.


Related

System login configuration entry settings for Java Authentication and Authorization Service

LTPA

(zos) Distributed identity filters configuration in z/OS security