Unifying Web Services Security

As e-business environments have evolved to Web Services models, security technologies
have been trying to keep up. As you’ll see throughout this book, we believe that
most of the pieces of the security puzzle exist, but that it still takes considerable effort
to put all these pieces together to build an integrated solution. Figure 1.3 provides an
overview of the different security technologies that need to be integrated.
Twenty years ago life was reasonably simple for the security professional. Sensitive
data resided on monolithic back-office data stores. There were only a few physical
access paths to the data, which were protected by well-understood operating system
access control mechanisms. Policies, procedures, and tools had been in place for many
years to protect legacy data stores.
Then, several years ago, Web-based applications burst onto the scene. With the
advent of e-commerce in this environment, secure access to Web servers was extremely
important. Today, there are many mature perimeter security technologies, such as SSL,
firewalls, and Web authentication/authorization servers, that enforce security between
browser clients and corporate Web servers.
Companies are now building complex e-business logic using Web Services in application
platforms in the mid-tier. These application platforms are commonly called
application servers or integration servers. (To simplify terminology, this book uses the
term application server to indicate any type of mid-tier application platform.) As we’ve
discussed, the business motivation for this development is compelling: Web Services
business logic allows accessibility to back-office legacy data in ways never imagined;
the opportunities for increased interaction among all kinds of buyers and suppliers
seem endless.
Security gets much more interesting when we introduce Web Service-enabled components.
Although there are many technologies that hook up Web servers to backoffice
legacy systems via a middle tier, the security of these approaches is often
nonexistent. In fact, several recent publicized attacks have been caused by weaknesses
in mid-tier security that have exposed sensitive back-office data (for example, customer
credit card numbers and purchase data) to the outside world. Companies are
usually at a loss for solutions to middle tier security problems.
To solve the thorny issue of securely connecting Web servers to back-office data
stores, we introduce the concept of end-to-end Enterprise Application Security Integration
(EASI). EASI is a special case of EAI (Ruh, Maginnis, Brown 2000).
EAI is a technique for unifying many different applications by using a common middleware
infrastructure. EAI provides an application “bus” that allows every application
to communicate with others via a common generic interface. Without EAI, an
application would need a separate interface for every other application, thus causing
an explosion of pairs of “stovepipe” connections between applications. EAI allows
application development to scale to a large number of interchangeable components.
We recognize that the integration of end-to-end security requires EAI techniques.
Many different security technologies are used in the perimeter, middle, and back-office
tiers. Typically, these security technologies do not interoperate easily. As a result, we
face exactly the same problem that application integrators face: Aseparate ad hoc interface
to connect one security technology to another causes an explosion of stovepipe
connection pairs between security technologies.
EASI (Heffner 2001) provides a common security framework to integrate many different
security solutions. We use Web Services security to bridge the security gap
between perimeter and back-office security. By using EASI, new security technologies
in each tier may be added without affecting the business applications. We’ll further
explore the concept of EASI in the next sections.
EASI Requirements
A key issue in enterprise security architectures is the ability to support end-to-end
security across many application components. End-to-end security is the ability to
ensure that data access is properly protected over the entire path of requests and
replies as they travel through the system. The scope of end-to-end security begins with
the person accessing a Web browser or other client program, continues through the
business components of the middle tier, and ends at the data store on the back-office
legacy system. The path may travel through both public and private networks with
varying degrees of protection.
In the enterprise architecture shown in Figure 1.4, a user accesses an application in
the presentation layer (for example, a Web browser client sends requests to a Web
server), which communicates to mid-tier business components (such as Web Serviceenabled
application servers). Frequently, the client request is transmitted through a
complex multitier chain of business components running on a variety of platforms.
The request finally makes it to one or more back-office legacy systems, which access
persistent data stores on behalf of the user, process the request, and return the appropriate
results.
To provide end-to-end security, each link in the chain of requests and replies must
be properly protected: from the initiating client, through mid-tier business components,
to the back-office systems, and then back again to the client. There are three
security tiers that make up any end-to-end enterprise security solution:
Perimeter security technologies. Used between the client and the Web server.
Perimeter security enforces protection for customer, partner, and employee
access to corporate resources. Perimeter security primarily protects against
external attackers, such as hackers.
Mid-tier security technologies. Used between the mid-tier business components.
Mid-tier security focuses primarily on protecting against insider attacks, but
also provides another layer of protection against external attackers.
Back-office security technologies. Address the protection of databases and operating-
system-specific back-end systems, such as mainframe, Unix, and Windows
2000 server platforms.
EASI Solutions
EASI solutions integrate security technologies across the perimeter, middle, and backoffice
security tiers. An EASI solution first and foremost consists of a security framework,
which describes a collection of security service interfaces that may be
implemented by an evolving set of security products. We’ll spend most of this section
describing our approach for defining an enterprise security framework. As you read
the rest of this book, keep in mind that we use this security framework to integrate
interfaces into all of the Web Service security technologies discussed.
In addition to the framework, an EASI solution also contains the software and hardware
technologies for securing e-business components. Chapters 3, 4, 5, 6, and 7
describe digital signatures and encryption for XML documents, WS-Security, SAML,
J2EE, CORBA, .NET, COM+, and many other security technologies that may be used to
secure Web Services components.
Finally, an EASI solution contains integration techniques, such as bridges, wrappers,
and interceptors, that developers can use to plug security technologies into a
middleware environment. To hook together different security technologies, EASI must
solve a key problem: defining a secure association between clients and targets that
establishes a common security context. The security context, which contains a user’s
identity and other security attributes, must be transferred across the system to a target
application. A user’s identity and security attributes form the basis for authorization
decisions and audit events, and must be protected as they are transmitted between
perimeter, middle, and back-office tiers, as shown in Figure 1.4. Because each technology
in these tiers represents and protects a user’s security information differently, integration
of the security context can be a rather difficult problem.
So how can one get a patchwork of different security technologies to interact with
and augment one another? The Organization for the Advancement of Structured Information
Standards (OASIS) is defining standards called WS-Security and SAML to
address this issue. WS-Security defines a standard way to attach security information
to SOAP messages, while SAML defines a format for exchanging authentication,
authorization, and attribute assertions. The combination of these two specifications
provides a description of the security context that can be passed across the tiers of an
architecture. WS-Security and SAML together are a standards-based approach for
expressing the security context that is not tied to any particular vendor’s application
environment or security product. Designed specifically for distributed security environments,
WS-Security and SAML are important building blocks for any Web Services
security framework. In Chapter 4, “XML Security and WS-Security,” and Chapter 5,
“Security Assertion Markup Language,” we’ll explore WS-Security and SAML in
depth; in Chapter 10, “Interoperability of Web Services Security Technologies,” we’ll
look at how WS-Security and SAML facilitate the exchange of an interoperable security
context across multiple Web Services security technologies.
EASI Framework
The EASI framework specifies the interactions among the security services and the Web
Services components that use those security services. By using common interfaces, it’s
possible to add new security technology solutions without making big changes to the
existing framework. In this way, the EASI framework supports “plug-ins” for new security
technologies. Key aspects of the framework are shown in Figure 1.5.
Applications
The security framework provides enterprise security services for presentation components,
business logic components, and back-office data stores. The framework supports
security mechanisms that enforce security on behalf of security-aware and
security-unaware applications.
Security-aware application. An application that uses security Application Programming
Interfaces (APIs) to access and validate the security policies that
apply to it. Security-aware applications may directly access security functions
that enable the applications to perform additional security checks and fully
exploit the capabilities of the security infrastructure.
Security-unaware application. An application that does not explicitly call security
services, but is still secured by the supporting environment (for example,
J2EE or COM+ container). Security is typically enforced for security-unaware
applications by using interceptors, which transparently call the underlying security
APIs on behalf of the application. This approach reduces the burden on
application developers to implement security logic within applications and
lessens the chance of security flaws being introduced.
Other applications, called security self-reliant applications, do not use any of the security
services provided by the framework. A security self-reliant application may not
use the security services for two reasons: because it has no security-relevant functionality
and thus does not need to be secured or because it uses separate independent
security functions that are not part of the defined EASI security framework.
APIs
The framework security APIs are called explicitly by security-aware applications and
implicitly by security-unaware applications via interceptors. Security APIs provide
interfaces for access to the framework security services. The framework supports standard,
custom, and vendor security APIs.
Standard security APIs. We encourage support for APIs based on open standards
or industry de facto standards. Examples of such standards are the J2EE
and COM+ security APIs described in this book in Chapter 7, “Security of
Infrastructures for Web Services.” These standards should be used whenever
possible because they are likely to provide the most stability and the most portability
across many different vendors’ products.
Custom security APIs. Custom APIs may be implemented when an enterprise’s
needs cannot be met by existing standard APIs. Custom APIs are required especially
when an enterprise uses a security service that is tailored to its business,
for example, a custom-rule-based entitlements engine developed internally by
an investment bank.
Vendor security APIs. As a last resort, vendor-specific proprietary APIs may be
used where open standards have not yet been defined. We recommend avoiding
the use of proprietary security APIs in applications if at all possible. Proprietary
APIs make it very difficult for the developer or administrator to switch security
products. Although vendors may think this is a great idea, we believe that security
technology is changing much too rapidly for an enterprise to be confined to
any one product. As an alternative, we recommend wrapping a vendor’s proprietary
API with a standard or custom API.
Core Security Services
The next layer of the security framework provides core security services enabling endto-
end application security across multitier applications. Each of the security services
defines a wrapper that sits between the security APIs and the security products. The
security services wrappers serve to isolate applications from the underlying security
products. This allows one to switch security products, if the need arises, by simply creating
a new wrapper, without affecting application code. The key security services are
authentication, authorization, cryptography, accountability, and security administration,
which we defined previously.
Framework Security Facilities
The framework provides general security facilities that support the core security services.
The framework security facilities include the profile manager, security association,
and proxy services.
Profile manager. Provides a general facility for persistent storage of user and
application profile and security policy data that can be accessed by other framework
services.
Security association. Handles the principal’s security credentials and controls
how they propagate. During a communication between any two client and target
application components, the security association establishes the trust in each
party’s credentials and creates the security context that will be used when protecting
requests and responses in transit between the client and the target. The
security association controls the use of delegation, which allows an intermediate
server to use the credentials of an initiating principal so that the server may act
on behalf of the principal. (Delegation is discussed in considerably more detail
in Chapter 11, “Administrative Considerations for Web Services Security.”)
Security proxy services. Provide interoperability between different security technology
domains by acting as a server in the client’s technology domain and a
client in the target’s domain.
Security Products
Implementation of the framework generally requires several security technology products
that collectively constitute the enterprise security services. Examples of such
required security products include firewalls, Web authentication/authorization products,
Web Service and component authentication/authorization products, cryptographic
products, and directory services. Several of these product categories are
discussed in this book. We describe CORBA, COM+, .NET, and J2EE security in Chapter
7, and we survey other relevant security technologies in Chapter 12.
EASI Benefits
At this point, the benefits of using a framework to address enterprise application security
integration should be clear. Our approach focuses on standards, which are the best
way to maintain Web Service application portability and interoperability in the long
run. Products and technologies will come and go, but generally accepted security standards
for fundamental security services will be much more stable. A standards-based
set of security APIs allows you to evolve security products over time without needing
to rewrite your applications. Designing your applications for evolving security products
is important because we believe that your business requirements and new security
technologies will continue to be a moving target. You might choose a great product that
satisfies your needs for the present, but you’ll probably want to change the product in
the future, and most people don’t want to be stuck with any one vendor’s product for
too long.
Having a security framework also means that you don’t need to implement everything
at once. The framework allows you to start small by selecting the security services
you need and building more sophisticated security functionality when and if it’s
required. The framework provides you with a roadmap for your security architecture,
helping to guide you on how to choose products and technologies that match your
needs over time.
Finally, the framework puts the security focus where it should be—on building a
common infrastructure that can be shared across the enterprise. Custom-built security
that is hand-coded within applications is expensive to implement and maintain and is
likely to have more security vulnerabilities. A single security infrastructure with APIs
that can be used by all of your applications avoids multiple, duplicate definitions of
users, security attributes, and other policies. You can focus your limited time and
money on building a few critical interoperable security technologies rather than coping
with a mass of unrelated security products that will never work together.
After we have fully explored the many aspects of Web Services security, we will
return to the theme of EASI at the end of this book. In Chapter 12, when we explain
how to plan and build integrated Web Services systems, we use EASI concepts to bring
the various security technologies together into a coherent security architecture.
Example of a Secure Web Services Architecture
Throughout this book, we use a simple e-commerce example to illustrate Web Services
security topics. Several of the chapters start with the basic scenario described here and
then extend the example in a variety of ways to emphasize specific security issues. In
this section, we introduce the basic example and provide an overview of its business
security requirements.
Business Scenario
Our application is a simple online storefront provided by ePortal, shown in Figure 1.6.
The store sells its products to customers, who can electronically place and settle orders
for products through customer accounts represented by shopping carts. Members are a
category of customers who get special treatment. Members have access to product
deals that are not available to regular customers. We also have two other classes of
users that access the storefront: visitors are casual browsers of the site, and staff administer
the storefront applications.
Users have two potential ways to access the services provided by ePortal. In the typical
consumer scenario, users access ePortal directly via a browser client. Browser
clients may reside anywhere on the Internet, and access the ePortal services via HTML
over HTTP (or HTTPS when SSL is used). Alternately, in a business-to-business (B2B)
scenario, ePortal users who are employees of a separate company, namely eBuyer,
access ePortal via Web Services applications. In this case eBuyer employees do not
access ePortal directly using a client browser; instead special-purpose applications in
eBuyer access ePortal services on behalf of the employees (who may use either a Web
browser to access the eBuyer application or perhaps use a customized user interface).
The applications access ePortal services via SOAP over HTTP (or HTTPS).
The services provided by ePortal are actually implemented by a third company,
eBusiness. ePortal accesses the eBusiness services via SOAP over HTTP (or HTTPS).
eBusiness stores information about products and prices, and also processes the orders
received by ePortal.
Why wouldn’t customers access the eBusiness services directly rather than going
through ePortal? There are several possible reasons. eBusiness may not be interested in
providing a direct Web presence for a large number of consumers, since such a service
requires maintaining authentication information for all users, protecting against denialof-
service attacks, and other complexities of a large-scale Web deployment. Furthermore,
ePortal may consolidate service offerings from many other companies besides eBusiness.
In this case, ePortal may provide the recognized consumer brand (such as those provided
by Amazon or eBay), and the consumer may not even be aware that eBusiness exists.
Web Services Interfaces
Figure 1.7 provides an overview of the Web Services implemented by eBusiness. As we
just described, eBusiness provides Web Services to ePortal, which in turn provides
these services to users.
The list below describes the eBusiness Web Service interfaces along with the methods
(operations) that each interface supports. For simplicity, we have omitted the operation
signatures that describe arguments and return values because these have little
relevance to the security policies that we will define.
■■ ProductManager is the object manager that returns Product instances.
■■ getProducts returns a list of ProductIDs that represents the inventory of
products that eBusiness is selling. (To keep the example simple, we don’t
provide an interface to add new products to the list.)
■■ lookup returns a Product instance based on a supplied ProductID.
■■ Product represents a product that eBusiness is selling.
■■ getPrice returns the price of Product.
■■ setPrice sets the price of Product.
■■ AccountManager is the object manager that returns Account instances. This
manager stores accounts (shopping carts) so a customer may retrieve them for
later use.
■■ create makes a new Account based on the CustomerID.
■■ delete removes an existing Account.
■■ lookup retrieves an existing Account based on the CustomerID.
■■ Account represents a customer’s shopping cart, which is a list of product orders.
■■ placeOrder puts an order into Account.
■■ deleteOrder deletes an order from Account.
■■ listOrders lists the orders in Account.
■■ settleOrder allows the customer to pay for the orders in Account with a
credit card.
For this scenario, we assume that the preceding interfaces have been implemented
on an application server containing J2EE, CORBA, COM+, or .NET components. Atypical
interaction would go something like this: Acustomer is first authenticated to ePortal.
com, and ePortal then gets a list of products and prices from eBusiness, using
getProducts and getPrice. The customer then places an order for products into his or
her account, which ePortal requests from eBusiness.com, using placeOrder. Sometime
later the customer settles the orders with a credit card number, which ePortal requests
from eBusiness.com by calling settleOrder.
Scenario Security Requirements
The Web Service security policies that we define in later chapters are based on the business
requirements for this example. Generally, it’s the combination of ePortal and
eBusiness security mechanisms that enforces the overall business requirements for our
example. We describe the business requirements for each class of user below.
Visitors. To entice new customers, ePortal permits visitors who are unauthenticated
users to browse the site. Visitors are permitted very limited access. Visitors
may:
■■ See the product list, but not their prices.
■■ Register to become a customer. Visitors may create an Account, which turns
the visitor into a Customer.
Customers. Most users accessing ePortal are customers who are permitted to
order regular products. Customers may:
■■ See the product list and prices for regular products, but not the prices for
special products, which are only offered to members.
■■ Place, delete, and settle (pay for) orders. A customer may not delete his or
her Account, however, and must ask someone on the ePortal staff to perform
this task. ePortal wants to make it difficult for customers to remove
their affiliation with the company.
Members. If approved by ePortal, some customers may become members. Members
have a longstanding relationship with ePortal and are offered price breaks
on special products. Other than having access to special products and prices,
members exhibit the same behavior as customers. Members may:
■■ See the product list and prices for regular and special products.
■■ Place, delete, and settle (pay for) orders. A member may not delete his or
her Account, however, and must ask someone on the ePortal staff to perform
this task. ePortal wants to make it difficult for members to remove
their affiliation with the company.
Staff. ePortal and eBusiness company staff members are responsible for administering
all aspects of the site. However, ePortal and eBusiness are concerned
about someone on the staff committing fraud by creating fictitious customers
and using stolen credit card numbers to order merchandise. To prevent this
exposure, people on the staff are not permitted to settle orders on behalf of customers
or members. Staff may:
■■ See the product list and prices for regular and special products and set
product prices.
■■ Assist a customer or member by placing, deleting, or listing orders on their
behalf. Staff may not settle orders, however—customers and members must
settle their own orders.
■■ Administer customer and member accounts, including the creation, deletion,
and looking up of the accounts.