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 






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

 

Our web partners: Inexpensive Web Hosting Java Web Hosting personal webspace webspace php  linux webhost

 html web templates DreamweaverQuality Web Templates PSD Web Templates

cheap webhost j2ee web Hosting buy webspace ftp webspace adult webspace

frontpage WebHosting webspace hosting cheap webhost

Visionwebhosting.net Business web hosting division of Vision Web Hosting Inc.. All rights reserved

aol web hosting