XML Web Services Security
, providing information and services to Web applications through well-define
d programmatic interfaces built on standard Internet protocols. A key benefi
t of XML Web services is the ease with which they can be accessed over the I
nternet compared to traditional distributed object models.
However, businesses creating XML Web services may not want to make these ser
vices freely available to everyone. Access to XML Web services can be restri
cted to authorized clients in much the same way that Web sites restrict acce
ss to authorized users. In addition to restricting access, an XML Web servic
e may need to ensure the privacy of data transmitted to and from clients, as
well as protect internal business logic and data stores used to implement t
he service.
This paper provides a high-level overview of mechanisms you can use to secur
e access to your XML Web services.
What Are XML Web Services?
An XML Web service is programmable application logic accessible using standa
rd Internet protocols. XML Web services combine the best aspects of componen
t-based development and the World Wide Web. Like components, XML Web service
s represent black-box functionality that can be reused without worrying abou
t how the service is implemented. XML Web services provide well-defined inte
rfaces, or contracts, that describe the services provided.
Unlike current component technologies, XML Web services are not accessed usi
ng object model–specific protocols such as the Distributed Component Object
Model (DCOM), Remote Method Invocation (RMI), or Internet Inter-ORB Protoco
l (IIOP). Instead, XML Web services are accessed using ubiquitous Web protoc
ols and data formats such as Hypertext Transfer Protocol (HTTP) and Extensib
le Markup Language (XML).
An XML Web service contract describes the services provided solely in terms
of the messages that the XML Web service accepts and generates. No informati
on about how the XML Web service is implemented is necessary in the contract
. Consumers of an XML Web service do not need to know anything about the pla
tform, object model, or programming language used to implement the service.
They only need to understand how to send and receive messages as specified b
y the XML Web services contract.
There are a few key specifications and technologies you are likely to encoun
ter when building or consuming XML Web services. These specifications and te
chnologies address five requirements for service-based development:
A standard way to represent data
A common, extensible message format
A common, extensible contract language
A way to discover services located on a particular Web site
A way to discover service providers
XML is the obvious choice for a standard way to represent data. Most XML Web
service–related specifications use XML for data representation, as well as
XML schemas to describe data types.
The Simple Object Access Protocol (SOAP) defines a lightweight protocol for
information exchange. Part of the SOAP specification defines a set of rules
for how to use XML to represent data. Other parts of the SOAP specification
define an extensible message format, conventions for representing remote pro
cedure calls (RPCs) using the SOAP message format, and bindings to HTTP. (SO
AP messages can be exchanged over other protocols, but the current specifica
tion defines bindings for HTTP only.) Microsoft .NET products will use SOAP
as the primary message format for communicating with XML Web services.
Note that the current SOAP specification does not define all the features de
velopers might expect to find in a traditional distributed object protocol,
such as object lifetime management, distributed transactions, or security. A
ll of these features could be defined as extensions to SOAP, but they are no
t defined as part of the base specification.
Most Internet-based scenarios should not require stateful objects or distrib
uted transactions, because both place server resources (for example, databas
e locks) under the control of remote clients. In practice, this means that t
he services exposed by an XML Web service are:
Stateless. All the information required to perform the service is either pas
sed in with the request message or can be retrieved from a data store based
on some information provided with the request.
Atomic. Each service represents a complete unit of work that leaves data sto
res in a consistent state. For example, if clients need to be able to move m
oney between bank accounts, the service should accept a MoveMoney request me
ssage, not just Debit and Credit requests.
Given an XML Web service, it would be nice to have a standard way to documen
t what messages the XML Web service accepts and generates—that is to docume
nt the XML Web service contract. A standard mechanism makes it easier for de
velopers and developer tools to create and interpret contracts. Several cont
ract languages were proposed during the past year: Service Description Langu
age (SDL), SOAP Contract Language (SCL), and Network Accessible Services Spe
cification Language (NASSL). All have been supplanted by a new language join
tly developed by Microsoft and IBM: the Web Services Description Language (W
SDL). WSDL is an XML-based language. Microsoft's developer tools that help c
reate and consume XML Web services are currently being updated to support WS
DL.
Developers also need some way to discover XML Web services. The DISCO (for D
iscovery of Web Services) specification defines a discovery document format
(based on XML) and a protocol for retrieving the discovery document, enablin
g developers to discover services at a known Uniform Resource Locator (URL).
However, in many cases the developer will not know the URLs where services c
an be found. Universal Description, Discovery, and Integration (UDDI) specif
ies a mechanism for XML Web service providers to advertise the existence of
their XML Web services and for XML Web service consumers to locate XML Web s
ervices of interest. There are three parts to the UDDI specification:
White pages, which provide business contact information
Yellow pages, which organize XML Web services into categories (for example,
Credit Card Authorization Services)
Green pages, which provide detailed technical information about individual s
ervices (this information may be provided by referencing discovery documents
or contracts)
The UDDI Business Registry is an implementation of the UDDI specification an
d is itself an XML Web service that uses SOAP over HTTP as its messaging pro
tocol.
Restricting Access to an XML Web Service
XML Web services can be implemented so that only authorized clients can acce
ss them. To restrict access to your XML Web service, you need a way to authe
nticate clients. Then, based on the credentials presented by the client, you
can decide whether to authorize access to the service.
In essence, securing an XML Web service is no different from securing a Web
site. But instead of authorizing end users to access the site, you will auth
orize computers or businesses to access the XML Web service.
If you know exactly which computers need to access your XML Web service, you
can use Internet Protocol Security (IPSec) or firewalls to restrict access
to computers of known IP addresses. This technique is particularly useful wh
en you want to restrict access to computers in a private network.
In most Internet scenarios, however, you will not know the IP addresses of a
ll your clients. In this case, the most straightforward approach to implemen
ting authentication is to leverage the authentication features of the protoc
ol used to exchange messages. For example, if you are sending and receiving
SOAP messages over HTTP, you would leverage the authentication features avai
lable for HTTP. Microsoft Internet Information Services version 5.0 supports
several authentication mechanisms for HTTP (see http://www.microsoft.com/te
chnet/iis/authmeth.asp for more details):
Basic
Use for nonsecure or semisecure identification of clients, because user name
and password are sent in plain text. Internet Information Services will aut
horize access to the XML Web service if the credentials match a valid user a
ccount.
Basic over SSL
Same as Basic authentication, except that user name and password are sent ov
er the network with Secure Sockets Layer (SSL) encryption rather than in pla
in text. A good option for Internet scenarios, although using SSL has a sign
ificant impact on performance.
Digest
Uses hashing to transmit client credentials in a secure way. However, not wi
dely supported on platforms other than Microsoft Windows. Internet Informati
on Services will authorize access to the XML Web service if the credentials
match a valid user account.
Integrated Windows authentication
Useful only for intranet scenarios. Uses NTLM or Kerberos. Cannot be used ac
ross proxy servers or other firewalls. Internet Information Services will au
thorize access to the XML Web service if the credentials match a valid user
account.
Client certificates
Requires each client to obtain a certificate. Certificates are mapped to use
r accounts, which are used by Internet Information Services for authorizing
access to the XML Web service. A viable option for Internet scenarios, altho
ugh use of digital certificates is not widespread at this time.
Another option is to implement a custom mechanism. For example, if you are s
ending SOAP messages, you can define your XML Web service contract so that c
lient credentials are passed in the SOAP message itself. With this approach,
you need to retrieve the credentials from the message and implement your ow
n authorization logic, but you can use any kind of client account database y
ou want. You can pass client credentials as a SOAP header or as elements in
the SOAP body.
Because SOAP messages are XML, if you are using a protocol such as HTTP to s
end the messages, the client credentials will be passed as plain text. If th
is is unacceptable, you could use SSL instead of HTTP.
Note that SSL is significantly slower than HTTP alone, so developers should
carefully weigh the tradeoffs between security and performance. It is possib
le to use SSL for some of the operations exposed by an XML Web service and m
ore lightweight techniques for operations where security is less critical.
If the performance overhead of using SSL for all secure operations is unacce
ptable, another authentication option is to use the SOAP RPC conventions and
define a special logon operation on your XML Web service that accepts crede
ntials as elements of the SOAP body and returns a session key. Only the logo
n method would need to be sent over SSL. Other messages could be sent over H
TTP, including the session key either in the SOAP header or the SOAP body. T
his approach runs the risk that the session key will be hijacked, but reduce
s the risk that a client’s password will be stolen.
You might wonder if Microsoft Passport could be used to restrict access to a
n XML Web service. In theory, Passport could be used to authenticate clients
of an XML Web service. However, Passport currently is targeted at authentic
ating end users, rather than applications, computers, or businesses. So in p
ractice, you may find that potential clients do not have and are not willing
to obtain a Passport.
Some XML Web services will have the need to authenticate end users. In this
case, you might expect Microsoft Passport to be useful. However, with the cu
rrent implementation of Passport, if a Web site is calling your service on b
ehalf of the end user, there isn't a secure way for the user to enter his Pa
ssport user ID and password and for the XML Web service to verify that the u
ser is logged in (and obtain the user's profile information, if necessary).
In general, if an XML Web service wants to authenticate an end user today, i
t must rely on client Web sites to pass on the user's credentials.
Protecting Data
In addition to authentication, the SSL protocol adds data integrity and data
privacy to HTTP. When SOAP messages are sent over SSL, they cannot be read
or modified in transit. If your XML Web service accepts messages containing
sensitive information, you may wish to have clients send the messages over S
SL.
If the overhead of SSL is unacceptable, another option is to encrypt individ
ual elements of the SOAP body. Digital signatures could be used to ensure th
at elements of the SOAP body have not been tampered with in transit. At the
moment, there is no standard for XML encryption or digital signatures, so yo
u would need to define a custom mechanism that your clients are willing to s
upport.
To further protect the data used by XML Web services, data stores may be kep
t inside the corporate firewall. Data stores outside the corporate firewall
should be locked down as much as possible—for example, by restricting acces
s to the XML Web service and administration programs.
David Chappell's Understanding Windows 2000 Distributed Services from Micros
oft Press® contains an excellent conceptual overview of how SSL works. F
or detailed information on providing data integrity and privacy, protecting
internal data stores, auditing, and protecting against attacks by unauthoriz
ed users, see Michael Howard's Designing Secure Web-based Applications for M
icrosoft Windows 2000 from Microsoft Press.
ASP Security Features
XML Web services hosted by application service providers (ASPs) use the same
authentication and authorization mechanisms described in this document to p
rotect against incoming messages from unauthorized users.
The business logic of XML Web services hosted on Windows-based platforms is
often implemented using COM components or managed classes targeting the .NET
platform. ASPs can further ensure that this business logic cannot be called
directly by running your XML Web services under a specific user account and
restricting access to the COM components or managed classes to that user ac
count.
Tools Support
ASP .NET Web services support sending and receiving messages over SSL, along
with all the HTTP authentication and authorization mechanisms supported by
the .NET Framework network classes, including Basic, Digest, and NTLM authen
tication. In addition, ASP .NET Web services support Microsoft Passport auth
entication and custom cookie-based authentication for applications that use
a private account database for authentication.
.NET Framework role-based authorization and code-access security can be used
by XML Web services implemented using ASP .NET.
The July 2000 release of the SOAP Toolkit for Microsoft Visual Studio® 6
.0 does not support any HTTP authentication mechanisms. Microsoft expects to
release an update to the SOAP Toolkit shortly that adds support for:
Sending and receiving messages over SSL
Anonymous, Basic, and NTLM authentication
Authenticating a client to an HTTP proxy
from:asp学习网/title:XML Web Services Security/ time:2007-6-13 23:13:56
本文主题Web Services
SQL Server 2005 自带的 Web Services SQL Server 2005 Native Web Services
