Chapter 7 Security

315

alone environment. If you develop a stand alone J2SE client to be a Web service

client, keep in mind that the J2SE platform provides its own set of services and

tools to help you. You can use the Java Authentication and Authorization Service

(JAAS), along with tools such as 

keytool

, to manage certificates and other secu 

rity artifacts. As just noted, you can also include the JAX RPC runtime, then use

its mechanisms to set up username and password properties in the appropriate

stubs and make calls to the Web service. It is important to have your client follow

the WS I interoperability requirements, since doing so ensures that your client can

communicate with any Web service endpoint that also satisfies the WS I interop 

erability requirements.

The J2EE container provides support so that J2EE components, such as serv 

lets and enterprise beans, can have secure interactions when they act as clients of

Web service endpoints. The container provides this support regardless of whether

or not the accessed Web service endpoint is based on Java. Let's look at how J2EE

components use the JAX RPC client APIs to invoke Web service endpoints in a

secure manner.

As indicated in the section  Endpoint Programming Model  on page 308, a

target endpoint defines some security constraints or requirements that a client

must meet. For example, the client's interaction with the service endpoint might

require basic authentication and HTTPS, or the client must provide certain infor 

mation to access the endpoint.

The first step for a client is to discover the security policy of the target end 

point. Since the WSDL document may not describe all security requirements (see

 Publicizing Security Policy  on page 313), discovering the target endpoint's

security policy is specific to each situation. Once you know the client's security

requirements for interacting with the service, you can set up the client component

environment to make available the appropriate artifacts. For example, if the Web

service endpoint requires basic authentication, the calling client container places

the username and password identifying information in the HTTP headers. Let's

take a closer look at what happens with both basic and mutual authentication.

For HTTP basic authentication, application server specific mechanisms, such

as additional deployment descriptor elements, are used to set the client username

and password. These vendor specific deployment descriptors may statically

define at deployment the username and password needed for basic authentication.

However, at runtime this username and identifier combination may have no rela 

tion to the principal associated with the calling component. When the JAX RPC

call is made, the container puts the username and password values into the HTTP

header. Keep in mind that the J2EE specifications recommend 

against

 using pro