Book Excerpt: Securing Web services
- By Bret Hartman, Donald J. Flinn, Konstantin Beznosov, Shirley Kawamoto
The following article is excerpted from Chapter 12
of 'Mastering Web Services Security' by Bret Hartman, Donald Flinn, Konstantin
Beznosov and Shirley Kawamoto. Used with the permission of the authors and John
Wiley and Sons.
Web services may have great potential, but they also have a huge problem:
they are too open. Companies need to limit access to their valuable resources,
whether they are patient records, credit card numbers, or manufacturing designs.
Enterprises want to collaborate and share information, but not at the expense of
giving away their assets. Companies need to keep their guard up and stay
suspicious of who they communicate with. They want to share enough information,
but not too much.
Before Web services will be successful, security must be in place. Companies
will never be willing to open up their internal corporate networks without the
proper countermeasures. If companies don't, there are several 'bad things' that
* External attacks. E-business applications exchange information that is
highly valuable -- this isn't about ordering a book from your browser at home.
E-business is about companies exchanging thousands of patient records or trading
stocks worth millions. For Internet-based Web services, attacks on these systems
can be mounted from any desktop machine in the world using very simple software
* Internal attacks. We've known for years that presumed trustworthy insider
employees perform most security exploits. They might be setting a trap door so
they can access corporate data after they leave the company. They might be
committing fraud by creating fictitious customers to trade stocks or order
What's so tough about security for Web
architects have known about the vulnerabilities we've described for a long time.
What makes Web services different?
* Web services are designed to be open and interoperable. Since firewalls are
set up to let HTTP traffic through, Web service requests via HTTP pass through
firewalls with ease, leaving the internal network exposed.
* Web services are all about connecting chains of applications together. A Web
service client communicates to one application, which proxies (delegates) the
request to others downstream. Security technologies based on PKI are
point-to-point, which work great for client-server but are completely inadequate
for securing chains of applications. Web services require security technology
that establishes trustworthy security associations in multitier
* The different companies participating in Web service transactions all use
different security products and technologies that don't interoperate. This
situation leaves companies with three options: turn off security (too risky),
agree on a single security technology (too expensive), or translate and bridge
between technologies (not always easy, but the best choice -- more on this
EASI principles for Web services
Security could easily be the
downfall of Web services. No company will be willing to deploy unsecured Web
services, but an approach based on a single security product is inadequate.
Where do you go from here?
To solve the problem of Web services security, enterprises need a solid
application security architecture in place based on principles of Enterprise
Application Security Integration (EASI). We recommend that you follow basic
principles of EASI when you define your own Web services security architecture.
We've learned these rules over the years as we applied EASI techniques to many
large customers' problems in banking, telecommunications, and manufacturing.
Security architecture principles
We begin our list of EASI
principles for Web services with some general guidelines for defining Web
services security architectures:
Trust no one: Web services applications are implemented by multitier chains
of requests, and consequently are much more complex than the client-server
model. A client request bounces through many applications, so there are many
points of vulnerability. As a result, corporate auditors have difficulty
establishing end-to-end system trustworthiness because systems don't match the
centralized TCB paradigm we described earlier.
A common simplistic model of trust is to have a security enforcement point at
the perimeter firewall, and then assume that all Web services applications are
equally trustworthy to protect all data. This approach is a dangerous
assumption, since firewalls usually permit Web services HTTP traffic to pass
through. If one component is compromised in this scenario, then the entire set
of distributed components is vulnerable.
Transport security mechanisms, such as SSL or Internet Protocol Security
(IPSEC), and message-oriented mechanisms such as XML Signature are inadequate by
themselves in multitier environments because they cannot secure a chain of
requests -- they only secure two end-points.
A better approach is to view collections of Web services components as
mutually suspicious islands -- if one collection of components is compromised,
then others will still be safe. In a mutually suspicious architecture,
authentication isn't only for people. Each component that is a part of a request
chain should be authenticated on its own.
To secure a multitier architecture, you need end-to-end security that
supports passing security credentials across many different applications, and
products that securely link users' credentials among systems to establish mutual
trust. Defining a security architecture for distributed trust and controlled
delegation is an advanced topic, and products that support these abilities are
just beginning to enter the market. The best solution we've seen so far is to
build Web services security on the combination of WS-Security and SAML, which
allows security credentials to be passed and validated at each component in the
Enable interoperability: You can't pick a single vendor product to solve Web
service security because your corporate customers and partners will pick
different ones. Your Web services architecture needs to have the ability to
interoperate with other Web services even when they use incompatible security
We've seen that there are many excellent point security solutions, but we're
quite confident that no single vendor product will ever satisfy all security
requirements and dominate the marketplace. Because there are so many possible
vendor security solutions out there, proprietary technologies can make
interoperability extremely difficult.
The best way to enable interoperability is to use vendor-neutral standards.
Although security standards for Web services are still in progress, they are
well on their way. WS-Security and SAML are the key standards in this area.
WS-Security provides a standard way to protect Web services message traffic,
while SAML standardizes how credentials may be passed across multiple
applications. These two complementary standards used together go a long way
toward supporting Web services secure interoperability in a vendor-neutral
Modularize security: Web service security technology will continue to evolve,
so it's important that you don't get roped into one vendor's product. All
companies need to have the flexibility to mix and match security technologies
without recoding their Web service applications.
Developers have the tendency to write their own security implementation
within their application. We think this is a practice that should be avoided
whenever possible. Developers cannot easily maintain the fragmented security
embedded in each application, and their security tends to be fragile, requiring
major rewrites when the security needs change. Look to enforce authentication,
authorization, and cryptography at the lowest practical level in the
architecture. The least desirable location is within the application, although
some policies cannot be enforced anywhere else. By pushing security down to the
lower layers of the architecture, you're more likely to produce robust common
security mechanisms that can be shared across many applications.
The best approach is for applications to use standard APIs to support modular
'plug-and-play' of security components from different vendors. A standard
security API defines a virtual security service that insulates applications from
dependencies on any specific vendor product.
Security policy principles
We continue our list of EASI
principles for Web services with some security policy guidelines for Web
services security architectures:
Authentication: Balance cost against
threat. The best authentication isn't
for everyone. The most secure authentication, such as public-key certificates on
smart cards, is probably too expensive to deploy and manage for many
applications. If authentication techniques are too strong, people may just give
up and not use the system. It's better to have authentication that people will
use rather than building a secure boat anchor. Single sign-on (SSO) is an
example of this principle; no one likes to login more than once.
driven. Authorization policies aren't really to
protect URLs or files: They protect business data that resides in those files. A
lot of time and money is wasted blindly setting up security products that do
little to protect important application data. To secure a system, don't lose
sight of the fact that the most important thing to understand is the purpose of
the business application. Once you understand what the business application is
for and what security failures you are worried about, you can then figure out
the best way to protect the data. (Application-driven authorization does not
mean that the authorization policy should be implemented within the
Accountability: Audit early, not
often. Auditing is expensive in distributed
systems, so for performance reasons, it's better to do it as little as possible.
Unlike authorization, it's preferable to push the source of an audit event to
the upper layers of the architecture near the application. Low-level auditing
(e.g., at the OS level) is extremely difficult to analyze because it takes
several low-level events to match to a single business transaction. Low-level
auditing is fine for discovering an attack on your OS, but correlating low-level
audit data across multiple audit logs to detect an application attack can be
close to impossible. As a result, the most effective auditing is done as soon as
an application recognizes that a potentially dangerous event has occurred.
Security Administration: Collections and
hierarchies for scale. Web services
applications are all about managing huge numbers: millions of users and
resources; thousands of servers. The best way to deal with large numbers is to
collect users and resources into groups and make those groups hierarchical. By
defining collections, administrators can set policies on lots of users and
resources at the same time and delegate security responsibilities across many
administrators. Note that collections do not just contain people; services and
data also should be grouped to handle scale.
For more on Mastering Web Services Security by Bret Hartman, Donald J.
Flinn, Konstantin Beznosov and Shirley Kawamoto, please go to the John Wiley and
Sons Web site at http://www.wiley.com/cda/product/0,,0471267163,00.html