Better Software - March 2009 - (Page 37) Table 3: Web service authentication data table service does not need to follow these standards to function; however, if you are planning for SOA or interoperability with other Web services, it is highly recommended. See the StickyNotes for links to a few of the Web service security standards. Even though we discuss security, our focus is on authentication. Many Web services require a user name and password, allowing the service to control access. Another reason for authentication may be pay per service, where you pay for access to a Web service for a designated amount of time or certain number of uses with access controlled by a user account. In the Sell Your Junk Web service, the account number supplied will be charged a posting fee. However, there are many Web services that allow anyone to connect with no authentication check at all. Many Web services use security or authentication tokens, which are embedded in the SOAP message header. These tokens may include information such as user name, password, or certificate allowing the authentication of the XML request. Since Web services are extensible, they are able to support multiple security token formats to accommodate a variety of authentication mechanisms. A few security tokens used in Web services include: • Username Token • X509 Token • Kerberos Token • SAML Token • SSL w/ 509 Client Authentication • HTTP Basic Authentication Mitigating the security risk can only be achieved through proper architectural planning with centralized security management and then properly testing this architecture. Centralized security management becomes critically important as you move toward multiple Web services and SOA. To validate authentication, we must understand the type of security token being used and what its property values should be. This may be new to many testers, since in Web applications you enter a user name and password and the application takes care of the rest behind the scenes. The Sell Your Junk Web service uses x509 certificates with a user name and password, giving us two types of authentication tests to perform—test the certificate (which will be new to most Web testers) and test the user name and password or authentication testing (with which we are all familiar). The x509 authentication testing can be easily performed using any commercial Web service test tool such as soapUI, Parasoft, Crosscheck, iTKO, or Mindreef. During validation, we want to test for a valid certificate, an invalid certificate, and no certificate at all. We will use valid functional test data and remove and replace the certificate through the mechanism the specific Web service testing tool provides. User name and password testing is performed as you would test any Web login page. With the same tool used during functional testing, enter different user names and passwords and valid data, ensuring that the XML response is correct. A sample data table is shown in table 3. with a number of other Web services? The owner of the Sell Your Junk Web service needs to know that the service can support the load if a number of people submit items to the Web service at once. Web services should be performance tested because of challenges inherent in the architecture of Web services. The loosely coupled, platform-independent functionality and connectivity is not free. It involves a substantial amount of communications overhead. Major performance problems are often due to layer upon layer of services: • Small services with large overhead • Large services that are under-supported by hardware • Services distributed across a network with their associated latency Stress and performance testing are needed to find concurrency problems caused by the many different code paths and timing conditions. A strategy for mitigating the risk of these challenges is to increase the intensity of tests including end to end, service by service, and interface by interface, ensuring all scenarios have been exercised. Performance testers should feel right at home testing Web services, using many of the same tools and applying the same strategies—repetition, concurrency, magnitude, and random variation—used every day in their Web performance testing. Repetition: Perform the same sequence of events over and over; for example, send the same XML request to a Web service again and again. This tells us if a service is fit for production, since typically Web services are used in a similar manner every time. We can repeatedly submit the same test that we created earlier during functionality testing. Concurrency: Execute several different test scenarios simultaneously or simulate multiple clients performing different operations by sending multiple XML requests to a Web service at once. This tests multi-threaded behavior in which code in one thread may be interrupted by code from other threads. As testers, we should mix valid and invalid test data together. Magnitude: Stress the system looking MARCH 2009 BETTER SOFTWARE Performance Testing Will the Web service perform well www.StickyMinds.com 37 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.