Appendix: Case Studies

This section of the book explains the technologies, products, and standards discussed in the rest of this book using several case studies of projects. This book started with a theoretical look at security, at Web Services, and at how security and Web Services relate together. This relationship works both ways: long-standing security problems may now be solved using Web Services, while the use of Web Services demands new security technologies. In this section, we look at how the technologies we’ve learned about can be put into practice. We will see various deployment models for Web Services security, including the use of authentication portals that talk to Web Services to present information to end users, and the use of XML gateway/XML firewall products to manage and control access to Web Services.

Local Government Service Portal

This first case study takes an old problem (deploying a Web site to a large user group whose members are authenticating using various methods) and applies a new solution (Web Services).

Project Overview

This project involved a local government authority that wishes to make available a range of services on its Web site portal to a variety of users, with varying levels of authentication and access granted depending on the identity of the user in question.

Web Services is attractive for government integration projects, because governments typically have very diverse and mutually incompatible systems, but also have a requirement for these systems to share information. Integration via a service-oriented architecture means that the various government systems do not need to be tightly integrated, which in turn means that technologies and solutions can be enhanced or swapped out without the change propagating to other systems and causing disruption.

The use of Web Services in government started with the use of Web Services within government systems, before the use of outward-facing Web Services. End users will continue to mainly use portals—not Web Services—for the foreseeable future to communicate with governments. Businesses, however, will migrate to the use of Web Services for government communication—for example, the filing of tax returns. The first step, underpinning these later steps, is for services-oriented architecture to be adopted for systems integration between government systems. Combined with Web Services security, this allows users authenticated through the portal to access services without the requirement to reauthenticate.

Security Factors Identified

The main security risk is the authentication issue. Although back-office systems are not being exposed directly using publicly available Web Services, an end user who has authenticated to the portal may request information that is fetched on their behalf using SOAP. In this case, it is important that information about the end user’s authentication travels with the SOAP message.

The use of a Web portal introduces Web site security challenges. It is important that the solution is not vulnerable to attacks mounted against the Web server itself, such as denial of service attacks and buffer-overflow attacks, or that it be vulnerable to attacks on other applications that are present on the same Web server.

Security Measures Deployed

It was decided that for the first release there would be two methods of user authentication available. One would be via a standard Web browser interface, using usernames and passwords over SSL. More trusted clients would be issued with client SSL certificates. Both these clients would communicate solely with the service portal. This would in turn communicate with the back-end systems using SOAP. The fact that there was no access to the back-end systems other than by authenticated users mitigated the concerns about these systems being compromised, but required that authentication cannot be bypassed. Web Services used in this project required the presence of a SAML authentication assertion issued by the government portal. This ensured that any attempt to bypass the authentication system and send a SOAP message directly to the Web Service would not be successful, because this SOAP message would not contain a valid SAML authentication assertion. As well as the use of SAML assertions within the SOAP messages, firewalls and routers are used to ensure that the internal Web Services use a private subnet, accepting no internal connections from the outside world.

WS-Security is used to package the user authentication information into the SOAP message. The SAML assertion conveys both the strength of the authentication and the identity of the user, thereby allowing the destination systems the autonomy to make their own decisions about which privileges should be granted.