home -> developer -> Web -> Methodology




The importance of methodology

In any activity that requires concrete results, a well-defined methodology for achieving those results is important. With a methodology, the process of achieving a result can be studied and the result verified. Without a methodology, this type of debugging and assurance is very difficult. Methodology is the bedrock upon which scientific study and engineering are built.

From a completely pragmatic point of view, a methodology helps you get things done. The most advanced tools are of little value if you do not know how to use them. A methodology helps you answer basic questions such as: "How do I accomplish this task?", or even, "What should I do next?". With a methodology, you are never left wondering where to start, or whether you are using a tool as intended.

This document describes the recommended methodology for building secure web services using WaterkenTM tools. Other tutorials describe how to apply this methodology using specific WaterkenTM tools. By studying these documents you can learn how WaterkenTM tools improve the security of your web services.

The role of methodology in web services security

A good methodology is particularly important to web services security because security is crucial for success, but complex to achieve.

The importance of web services security sometimes becomes clouded by the hype and commerce surrounding technical arcana. The purpose of creating a web service is to provide new participants with controlled access to an existing service. If security were not the driving issue, new participants could just use the existing interface. For example, when providing bank customers with direct access to their accounts, a new interface is created instead of giving customers access to the bank tellers' interface. The driving issue is to create an interface that correctly restricts the customers' authority.

Software is about exchanging information and authority. Security is about controlling how information and authority are exchanged. The design of software and the security of software are necessarily intertwined issues. Widely held industry tenets, such as: "security has to be designed in from the start", are a recognition of this intertwining.

Software products that encourage treating security as an "add-on" typically try to characterize security as something that is extraneous to application "business logic". As is explained here, such characterizations are misguided. The main point of a web service is to provide controlled access to a service. In a web service, security *IS* your business logic.

Capability-based security

At the core of the web-calculus methodology is an established, general purpose, software security model: capability-based security. A capability is an unforgeable pointer that both identifies and authorizes access to a resource. The only way to access a resource is through a capability that identifies the resource. A client may only come to possess a capability by receiving the capability from another client, already in possession of the capability, or from the creator of the resource. This constraint requires that a capability only be transmitted using a medium that prevents eavesdropping, such as an encrypted communications channel. [links]

In contrast to the Access Control List (ACL) model, which emphasizes the principal, the capability-based model emphasizes the resource as the main vessel for authority. In a capability-based design, authority is divided into separate resources. Each different authority in a capability-based design is embodied as a separate resource. Clients are authorized to use a service by being given a collection of capabilities.

The capability-based model and the ACL model take fundamentally different approaches to access control. The purpose of access control is to prevent the processing of illegal requests. The ACL model uses an external list to determine if a particular request is legal or illegal for a particular user. In the capability-based model, the user is unable to create an illegal request. Making a request requires naming the resource that will serve the request. In the capability-based model, the user is unable to name resources that he is not authorized to use. A name that enforces this property is called a capability.

Capability design with web-calculus tools

The WaterkenTM web-calculus tools are designed to integrate the capability-based security model into the design and deployment of a web service.

A WaterkenTM web-calculus server connects to your application via a collection of resource definitions. Each resource definition represents a subset of the functionality exported by your application. This resource-centric division of authority forms the overall framework within which application functionality is created. By ensuring that functionality is created in this resource-centric way, the framework ensures that access control can be done via the capability-based model.

The division of application authority into resources is the critical step in the creation of your application security policy. The rest of the WaterkenTM web-calculus framework is designed to enforce the security decisions made in this design phase. Focus on creating the appropriate authority divisions in this design phase and the WaterkenTM web-calculus server will handle the rest. At runtime, the WaterkenTM web-calculus server will automatically serve requests to these exported resources, routing the requests through the resource definitions to ensure that the properties of capability-based security are never violated.

Auditing application security

Dividing authority into small, discrete resources greatly facilitates security auditing. A security audit of a web service begins by identifying the resources that embody the audited authority. Determining the rules that govern use of the authority is simply a matter of studying the corresponding resource definitions. The power of this approach is that a security audit can be done piecemeal, verifying individual security properties without having to simultaneously verify total application security.

Integrating existing applications

Defining an interface solely in terms of exported resources provides great implementation freedom. A resource is a very generic concept that can be implemented in many different ways. Since a WaterkenTM web-calculus server operates exclusively via resource definitions, integrating existing applications and data sources is straightforward.

A secure web services interface to an existing application is built by defining a collection of resources that embody the desired authority divisions. Each resource is implemented to provide access to the corresponding part of the existing application. A WaterkenTM web services server can then be used to securely route requests to the existing application, through these resource definitions. By surrounding an existing application with a web of resource definitions, even applications that were not originally designed with security in mind can be integrated into a secure web service.


A resource-centric design is also a powerful approach to development of scaleable and interoperable software. In web development, this approach is commonly referred to as "webizing". Webizing an application means making its data and functionality accessible using the technologies of the WWW: URL, XML and HTTP.

A WaterkenTM web-calculus server automatically provides a webized interface to its collection of resources. Each exported capability is represented as an unguessable URL. The WaterkenTM web-calculus server will serve requests on these URLs in a variety of standard formats such as: HTML form POSTs, GET requests, or XML. The results of a request will be automatically encoded in XML.

Web applications

Many web services provide access to applications that are used not only by other software, but also by human users via a web browser. A web service with an HTML user interface is called a web application.

The WaterkenTM web-calculus server provides a security-conscious approach to extending a web service into a web application. The server allows an XSLT stylesheet to be associated with each resource type. This transformation will be automatically applied to the generated XML before returning a response to the client. Using this feature, you can extend your web service into a web application by generating HTML for web browser clients.

This approach to web application development provides important security advantages. Since the web application is created solely as a transformation of the web service interface, all security-critical decisions remain localized to the resource definitions. The XSLT code interacts with the application through the same capability-based, secure interface that any other software client uses. This framework effectively renders the XSLT code security-neutral, which is important since user interface code typically makes up the bulk of application code. Reducing the amount of security-critical code in an application makes verifying the security of the application much easier. The layering of web application on top of web service also creates important role divisions. The XSLT programmer need know nothing about security, since application security cannot be violated by the XSLT code.

The WaterkenTM approach to web applications stands in sharp contrast to competing approaches. Other approaches typically involve using proprietary HTML formats with embedded programming code. This programming code has the same level of access to the application as the web services code. Essentially, the human interface becomes yet another interface to the application, requiring that the security policy be again expressed and enforced. Requiring that a security policy be expressed in multiple different ways, in multiple different places, is a recipe for failure. Using the WaterkenTM approach, the security policy is expressed once and always enforced in the same way.

The separation of business logic from UI code is also useful for non-security reasons. Approaches that force UI code and application code to reside in the same file can cause development conflicts. Frequently, different developers are responsible for the different types of code. Putting the different types of code in the same file results in neither developer "owning" the file. Using XSLT means that web interface designers can use a familiar language and generate files that they completely own.

The XSLT stylesheets can also be used to generate other user interface formats, or even just XML that uses a different DTD. If you need to generate XML that conforms to an existing DTD, you can use XSLT stylesheets to transform the automatically generated XML code to match your DTD.


This paper has outlined a development methodology that integrates security into all aspects of web services development. Armed with this methodology and WaterkenTM tools, you can begin creating web services that make real, verifiable, security guarantees.

The crucial step in this methodology is the division of application functionality into resources. Deciding how best to do this is a non-trivial task that requires thought and experience. If you would like assistance or training in capability-based software design, contact Waterken Inc. for consulting services.

Continue learning about web-calculus security by learning how to apply this methodology using specific tools. See:


[links] More information on capability-based security can be found at:


Copyright 2002 - 2003 Waterken Inc. All rights reserved.

Valid XHTML 1.0! Valid CSS!