Common Secure Interoperability inbound authentication settings

Common Secure Interoperability inbound authentication settings

+
Search Tips | Advanced Search

Use this page to specify the features that a server supports for a client accessing its resources. To view this console page, complete the following steps:

Click...
Security | Secure administration, applications, and infrastructure | Authentication | RMI/IIOP security | CSIv2 inbound authentication

You can also view this console page on the server page by completing the following steps:

Click...
Servers | Application servers | server | Security | Server security

Under Additional properties, click CSIv2 inbound authentication.

Use common secure interoperability (CSI) inbound authentication settings for configuring the type of authentication information that is contained in an incoming request or transport.
Authentication features include three layers of authentication that you can use simultaneously:

Transport layer.
The transport layer, which is the lowest layer, might contain an SSL client certificate as the identity.

Message layer.
The message layer might contain a user ID and password or an authenticated token with an expiration.

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.

Configuration tab

Basic authentication

Specify that basic authentication occurs over the message layer.
Basic authentication occurs in the message layer. This type of authentication typically involves sending a user ID and a password from the client to the server for authentication.
This authentication also involves delegating a credential token from an already authenticated credential, provided the credential type is forwardable, for example, LTPA.
If you click Basic Authentication and LTPA is the configured authentication protocol, user name, password, and LTPA tokens are accepted. The following options are available for Basic Authentication:

Never

This option indicates that this server cannot accept user ID and password authentication.

Supported

This option indicates that 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

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

Basic authentication takes precedence over client certificate authentication, if both are performed.

Client certificate authentication

Specify 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 performed. 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, you only need the CA root certificate in the server signer section of the SSL trust file.
When the certificate is authenticated to a Lightweight Directory Access Protocol (LDAP) user registry, the distinguished name (DN) is mapped based on the filter that is 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.
The identity from client certificates is used only if no other layer of authentication is presented to the server.

Never

This option indicates that clients cannot attempt Secure Sockets Layer (SSL) client certificate authentication with this server.

Supported

This option indicates 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.

Required

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

Trusted identities

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.

Data type String

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 (the server failed and resumed operation). When this value is disabled, every method invocation must authenticate again.

Data type String

Login configuration

Timeype of system login configuration to use for inbound authentication.
You can add custom login modules by clicking Security > Secure administration, applications, and infrastructure. Under Authentication, click Java Authentication and Authorization Service > System logins.

Security attribute propagation

Select this option 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.
Verify that you are using LTPA as your authentication mechanism. LTPA is the only authentication mechanism supported when you enable the security attribute propagation feature.
To configure LTPA, click Security > Secure administration, applications, and infrastructure. Under Authentication, click Authentication mechanisms and expiration.
If you do not select this option, the appserver does not accept any additional login information to propagate to downstream servers.

Related tasks

Configure Common Secure Interoperability V2 inbound authentication

Related Reference
System login configuration entry settings for Java Authentication and Authorization Service
Authentication mechanisms and expiration

Reference topic