Tài liệu Java Testing and Design- P8 doc

Getting a Head Start 329

The HTTPS_Connect agent gives a very simple example of interacting

with a Web host over an SSL connection. We will see later that SOAP-based

Web-enabled application requests and responses may be made using SSL

too. First, we investigate the problems SSL potentially adds to a Web￾enabled application environment.

What Usually Goes Wrong in SSL Systems

SSL is widely implemented as a software-based solution. In this implementa￾tion, the server negotiates the SSL connections with clients and performs

encryption and decryption at the software level. The SSL handshake, in

which the client and the secure server negotiate the choice of algorithm and

keys, is an extremely processor-intensive operation. Running the HTTP

_connect test agent in the previous section demonstrates the overhead of a

secure connection. At some point the server runs out of resources (CPU

bandwidth, memory, or network bandwidth) when performing the hand￾shake to run the secure application. Network managers often overcome this

limitation by adding more powerful servers.

Another way of going is to add an individual SSL accelerator card to the

server. Experience shows that while SSL traffic does not significantly affect

overall network traffic, it does tax the servers that process network traffic.

Adding an SSL accelerator card to each server offloads the SSL work to the

coprocessor on the card and enables the Web application on the server to

respond in normal time.

In a Flapjacks environment, network managers find that the extra expense

of adding SSL accelerator cards to every server can become overwhelming.

Each server handling encrypted content requires an SSL accelerator card

and a digital certificate. To obtain a digital certificate for each server from a

certificate authority (CA), administrators must create a public key–private

key pair and a Certificate Signing Request (CSR), and then submit these

items to a CA. This process must be repeated for every server in production.

Digital certificates are valid for a limited time only, and administrators must

renew each certificate each time it expires.

Not only is the management of these SSL-enabled servers time-intensive,

it is also costly. Technological advances have reduced the cost of SSL acceler￾ator cards, but they are still expensive. And each time a certificate expires, it

must be repurchased from the certificate authority. These expenses signifi￾cantly increase the total cost of procuring and managing the SSL-enabled

servers. As a result, while testing Web-enabled applications in secure envi￾PH069-Cohen.book Page 329 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

330 Chapter 10 Building and Testing Intranets and Secure Environments

ronments, the test will usually turn up one or two expired certificates. While

it is possible to continue testing using temporary certificates, the results may

not be meaningful.

Like any security technology, digital signatures used in the SSL model are

fallible. If the certificate authority’s root key is stolen, then anyone can create

digital certificates, which compromises the trust level of the certificate author￾ity and makes all the certificates from that certificate authority null and void.

Certificate authorities go to great lengths to keep their keys secure, including

armored bunkers. Additionally, if the user loses his private key or if it is stolen,

then anyone possessing the private key can assume the user’s identity.

Unfortunately, in today’s business environment SSL is not universally

used. But it is becoming more accepted. Languages, platforms, and certifi￾cate authorities now all support SSL and work hard at reducing all the com￾plexity behind keys, hashes, and digital certificates.

SOAP over SSL

The SOAP specification purposefully avoids describing mechanisms for

securing requests and responses. The early SOAP-based Web-enabled appli￾cations use SSL to encrypt the SOAP request and response documents. Later

in this chapter we will see why SSL is not very well suited to secure SOAP￾based Web-enabled applications. But for now we show how to use SSL in a

SOAP environment.

SOAP implementations run on top of application server and Web server

technology. It should be no surprise then that the SOAP requests may be

made over SSL-encrypted connections. The TestMaker framework builds

intelligent test agents that can communicate with Web-enabled application

hosts using SOAP protocols over SSL using the techniques shown in the fol￾lowing test agent script:

# Import tells TestMaker where to find Tool objects

from com.pushtotest.tool.protocolhandler import \

ProtocolHandler, SOAPProtocol, SOAPBody, SOAPHeader

from com.pushtotest.tool.response import Response

from java.lang import Long

# Set the default values defining the location of the host

host = "examples.pushtotest.com"

port = 92

path = "axis/servlet/AxisServlet"

PH069-Cohen.book Page 330 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Getting a Head Start 331

endpoint = host + ":" + str( port ) + "/" + path

# Create a SOAP object to communicate with the host

protocol = ProtocolHandler.getProtocol("soap")

# over an SSL encrypted connection

protocol.setScheme( "https" )

body = SOAPBody()

protocol.setBody(body)

# Set the endpoint values

protocol.setHost( host )

protocol.setPath( path )

protocol.setPort( port )

body.setTarget( "responder_rpc" )

body.setMethod( "Respond" )

body.addParameter( "wordcount", Long, 150, None )

body.addParameter( "delay", Long, 100, None )

print "Sending request to server..."

response = protocol.connect()

print "Here is the response:"

print response

print

print "Agent done."

With the exception of the setScheme() method, this is the same agent

presented in earlier chapters. The setScheme() method tells the SOAPPro￾tocol object referenced by the protocol variable to use an SSL connection to

communicate with the host.

.NET Passport Authentication

Microsoft .NET Passport is a single sign-in system that enables developers to

defer their user authentication to .NET Passport servers. (Chapter 9 intro￾duces the Microsoft .NET framework for building Web-enabled applica￾tions.) To provide this service Microsoft uses a combination of keys and

configuration files that ensure user identity.

PH069-Cohen.book Page 331 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

332 Chapter 10 Building and Testing Intranets and Secure Environments

Early .NET applications used SSL encryption to secure SOAP requests

and responses between the application and Passport servers. Later in this

chapter we will see why SSL is not very well suited to secure .NET-based

Web-enabled applications. For now we will give a brief overview of the secu￾rity technology Passport provides.

From the standpoint of a Web site implementing .NET Passport single

sign-in, .NET Passport Manager is the main service interface. Passport Man￾ager has traditionally been a Microsoft COM server that could be used from

ASP. However, the .NET Framework implements most of the same function￾ality in managed code via the PassportIdentity class.

During authentication, .NET Passport Manager is responsible for provid￾ing a link to the .NET Passport servers with all appropriate data in the query

string so that the .NET Passport servers can perform the appropriate valida￾tion and return the user to the suggested site. .NET Passport Manager uses a

combination of input parameters, registry settings, and data stored on the

.NET Passport servers about your site to give the .NET Passport servers the

information they need to perform the authentication with the requirements

of the site. When authentication is established, the user browser redirects to

the site and cookies are set to hold the user’s .NET Passport ticket and profile

information for subsequent requests. For details on Passport, go to http://

msdn.microsoft.com/webservices/ and http://msdn.microsoft.com/downloads/

default.asp?url=/downloads/sample.asp?url=/MSDN-FILES/027/001/644/

msdncompositedoc.xml&frame=true.

HTTP Basic Authentication

The HTTP protocol defines a basic authentication method that provides very

simple security to protect the results of an HTTP request. In an HTTP/

HTML environment—as described in Chapter 6—a Web host optionally

requires the HTTP header to contain user id and password entries to submit

the request.

If the HTTP headers are missing, then the server responds with a 401

Unauthorized error code. Rather than display the 401 Unauthorized error

code, most browsers display an alert that asks the users to type in their id and

password. The browser then submits the same request plus the additional

HTTP headers containing the id and password.

TestMaker supports HTTP basic authentication in its HTTPProtocolHan￾dler object. In the following excerpt of an intelligent test agent imple￾mented in TestMaker, the http.setUsername() and http.setPassword()

PH069-Cohen.book Page 332 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

SOAP and Security 333

methods define the id and password to be sent to the host in the HTTP

header.

from com.pushtotest.tool.protocolhandler import ProtocolHan￾dler, Body

http = ProtocolHandler.getProtocol("http")

http.setUsername("MyName")

http.setPassword("MyPassword")

...

http.connect()

HTTP Basic Authentication should be used only for the least security

risks. HTTP Basic Authentication expects to find a user id and password in

the HTTP header of a request. The header information moves across the

Internet in clear text so anyone with a network monitor can see the unen￾crypted id and password information.

SOAP and Security

Most first-generation Web-enabled applications were deployed in internal

integration projects behind a company’s firewall. However, some companies

are now deploying Web-enabled applications to expose internal systems over

the Internet to business partners, vendors, and customers. Early adopters of

Web-enabled applications technology can be found in the financial, govern￾ment, and healthcare sectors, where risk of attack is greater as the data

exchanged is often sensitive or high-value in nature.

SSL is effective to encrypt and authenticate SOAP-based Web-enabled

application communication in first-generation Web-enabled applications.

These early services typically move messages only between two points. SSL

does fine in this environment. The SOAP client obtains a copy of the server

certificate, authenticates the server, and establishes an encrypted channel.

The problem with SSL appears in B2B transactions. SOAP interfaces of

Web-enabled applications access advanced functionality that business-to￾consumer Web-enabled applications would not be able to access. For exam￾ple, a Web site in a B2C application does not need the client certificate to

carry out a sale of a low-priced item like a videotape or a pillowcase. In a B2B

environment where the risk of making a mistake is higher, the SOAP host is

more concerned about authenticating the client.

PH069-Cohen.book Page 333 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.