InfoCenter Home > 5.7.1: SAS on the client sideWhen an enterprise-bean client, for example, a Java client, a servlet, or another enterprise bean, invokes a remote method, SAS interceptors are called to do the following work on the client side:
Establishing an SSL connectionEstablishing an SSL connection requires information from both the client and the server prior. The client obtains some of this information from the client-side property file, sas.client.props. Some of the information must come from the server, which stores the information with the naming service. To contact a server, the client retrieves information about the server from the naming service. The returned information includes an interoperable object reference (IOR), which the client uses to determine the type of connection expected by the server. If global security is enabled within WebSphere Application Server, servers insert a structure of security information, called a security tag into their IORs before registering the IORs with the naming service. The information from the security tag in the IOR and from the sas.client.props file is sufficient for creating an SSL connection. If the necessary information for an SSL connection is not present, a TCP/IP connection is created instead. For example, if the client does not find a security tag in a server's IOR, an SSL connection cannot be created. If the target method is secured, the request must come in on a secure connection. Requests coming in on a TCP/IP connection always fail for a lack of permission provided the method being invoked is protected; no credentials are created for a TCP/IP connection. A typical error message that indicates this condition is: authorization failed for / while invoking method A If global security is enabled, RMI/IIOP connections are typically made using SSL. There are a few exceptions, for which TCP/IP connections are automatically made. These exceptions include name-server lookups, is_a queries, and a few other special methods. SSL connections are always the default for business methods. The pure Java client or server acting as a client (that is, by making an outgoing connection to another server) gets some of the information it needs from the object's IOR from the server. Additional information is obtained from the client properties file. For a pure Java client (one that executes in a separate process from the server), the properties file used is the one specified on the com.ibm.CORBA.ConfigURL property on the Java command line. This is usually the sas.client.props file. For a server acting as a client, the property file used is the sas.server.props file on the server system. Some of the information in the sas.server.props file can only be changed by using the administrative console. Other parts of the sas.server.props file can be changed using a text editor. Most of the SSL and login configuration is done by using the Security Center in the administrative console and written into the WebSphere Application Server repository. After the administrative server restarts, the configuration information is migrated from the repository to the sas.server.props.future file. It is then merged into the sas.server.props file, which is used when the adminstrative server restarts. The property file for an application
is specified as a Java property on the command line when the application
is started. The property,
You can verify the URL syntax by following the URL with a browser on the system where the file resides. If the browser can read the file, the URL is valid. The com.ibm.CORBA.ConfigURL property is typically specified on the java command line of the client program by using the -D option in front of the property. The information required before SAS can make a secure connection is shown below. Information obtained from the server's IORThis section describes the information retrieved on the client side from the server's IOR and lists possible server-side sources for that information. For example, some of the information in the IOR comes from server-side properties.
Information obtained from the client's propertiesThis section describes the information retrieved on the client side from the client's properties files.
This information is used by SAS to construct the SSL connection to the server. During this process, the client uses the public key in the key store file to secure messages. WebSphere Application Server provides several dummy keyring files for use in test and development environments. These keyring files should not be used in a production environment where message protection is desired. The certificate in this keyring file can be used to do valid encryption, but the private key needed for decrypting the messages is readily available. During the SSL handshake between the client and server, the quality-of-protection level for the connection is determined by evaluating the client and server settings; the result is called the coalesced QOP. If the server setting is higher than the client setting, the server setting is used for both. The server setting is the minimum acceptable level for the connection. If the client setting is higher but the server supports the higher level, then the client setting is used. If the server does not support the higher level offered by the client, the client uses the server setting. The coalesced QOP value is used to determine the cipher suite to use when creating the SSL connection. The value determines the characteristics of the SSL connection as follows:
In cases where client authentication is required but the login information is not specified, the message is sent over an insecure TCP/IP connection. Ensure that methods are protected using authorization if you do not want unauthorized users to access them. When a TCP/IP connection is used to access a protected method, an authorization failure occurs. Establishing a secure association between the client and serverOnce a connection is created at the server, SAS requires that a secure association between the client and server be established. This entails authenticating the client on the server side and establishing a SAS security session on both the client and server sides. Most problems that occur with authentication will happen during this process. This is where the server authenticates the client and returns success or failure. In many cases where a failure occurs, you can expect to receive a NO_PERMISSION exception. To get more information from the exception, use the getMessage() method to get a text description about the failure. Sending the request to the serverAfter the SSL connection is created and a secure association is established, the client's request is sent to the server. Receiving a response from the serverOnce the server processes the request it sends a response back to the client. The SAS client processes the response to determine if it was successful or not. If not successful, it will throw an exception to the business client to handle. Some of the exceptions you can expect to see are: The exception is usually one of the following:
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|