Web Service Availability, Deployment at Center of Security Process

Web service availability -- the process of making services available in a service-oriented architecture (SOA) -- is a fundamentally different process than that associated with traditional applications. When IT publishes an information service in a traditional application, this is, practically speaking, nearly the end stage for that service. By contrast, when IT publishes a service in a SOA -- into the production environment -- this is just the beginning.

Web Service Availability in the Shared Service Environment

Consuming applications or users may have one use for the service at first, but later, new uses for that service will inevitably arise. Soon enough, users will want to use the service in unexpected ways [see diagram below]. Thus, one of the challenges in a SOA is to make services flexible enough so that they can indeed support these multiple uses.

For example, perhaps a particular service was originally built to be used internally, but now a partner wishes to take advantage of it. One of the central challenges then is Web service availability: how to take a service and make it available in the broadest sense? This means availability across different kinds of security mechanisms, transports, and other ways of accessing the service. Even different schemas: industry-specific schemas, for example. One of the challenges, then, with a service center is to be able not only to build the service once, but after it's in production, IT must be able to provision the service with multiple different mechanisms in use.

Web services availability across information "silos" in the new shared services environment

Web Service Availability and Access Demand "Granular" Security

As more people begin to use a deployed service, the greater the potential for issues to arise with regard to trust and security associated with the individual uses of that service. Not everyone should necessarily have access to all the information that a service is capable of providing. To clarify: this point does not imply an "on/off" or broad-brush, "access/deny" approach to security. Instead, a very granular security method is called for. IT may have to filter or even sign or encrypt very specific pieces of information associated with a service.

Web Service Availability and Security Case Study

Following is a simple case study involving a licensee record in a database. In this scenario [see diagram below], there are some cases in which it may be acceptable to return a Social Security number (in response to a query) to a broad audience. But in other cases -- perhaps because of privacy regulations, for example) the Social Security number may have to be filtered out. This sort of security requirement is just one example of the kinds of challenges IT organizations face as they begin to expand the use of a service.

In the world of Web service availability, access control and security, all information is not created equal: even within a message

So it's not enough just to have simple Web service availability, access control and authorization. IT shops need to have fine-grained control over the exact content of messages so they can understand exactly how different elements of content are handled and used. This initial challenge is typically addressed by Web Service infrastructure products that obviate the need to figure out and build logic into SOA applications.

Should "Consumers of Consumers" Have Web Service Availability?

Another challenge IT organizations face as they make an information service available to broader audiences -- outside of the company, for example -- is the issue of trusting the various types of service consumers out there. Some consumers may be "trustworthy", while IT may not be so sure of others: so only a subset of the consumers may be trusted.

Yet some of those "trusted" consumers may in fact be making the service available downstream to other "not-so-trusted" users. A situation can therefore easily arise in which IT cannot necessarily trust (or even know about) all the users of a given service; this scenario can have some meaningful side effects. For example, let us imagine that IT releases an information service like the one on the left [see diagram below] that accesses licensee information. Typically, one would expect someone to simply request the ID number from the database application and get back the desired data.

But let's say this service is exposed to a particular consumer who then makes it available to some partners of his -- who are not "officially trusted" by the organization. These partners might then use the service in ways that IT never anticipated. Here we have an example of a consumer who appears to be accessing a licensee, but instead, the user is actually deleting one of the records from the database. This process is called a SQL injection attack.

SOA Management Secures Web Service Availability

Not anticipating these kinds of attacks, IT would not have taken care to construct the application such that it would forbid quotes in the middle of a licensee number. The bottom line, however, is that a SOA management infrastructure is required to detect these kinds of attacks -- at a higher level of abstraction -- in order to assure that the SOA isn't compromised by untrusted, partially trusted, or just plain malicious, users.

For More Information

Discover the limits of Web service availability; learn why deployment is just the beginning: download the free webinar, How Enterprises Can Leverage SOA to Share Information Securely