mnystrom@cisco.com
Abstract
Historically,
this was fine, since the applications accessible through these routes were
deliberately created for consumption by web browsers external to the company.
The problem is that SOAP will use these same connections to expose new kinds of
applications. For example, consider allowing one of your largest customers to
cancel orders via a SOAP request.
This is a sensitive operation, requiring strong authentication,
authorization, and non-repudiation.
However, this firewall is configured to allow any kind of valid TCP
packet through these ports, regardless of what’s in it. Therefore, this sensitive web service is
naked and exposed to the world. Of course, it’s easy to configure the web server
to require authentication by the client application (treating it as if it were a
user.) Still, you can see that the
ease of access to a web service is a double-edged sword:
"One good thing about SOAP: By using HTTP you can send
messages right through the firewall.
One bad thing about SOAP: By using HTTP you can send messages right
through the firewall." Anthony Nadalin [4]
B.
Securing the Pipe is Not Enough
HTTPS (HTTP over SSL) has served well
as a tool for encrypting private information. Millions of consumers rely on it
every day to hide their credit card numbers when they make purchases on the
Internet. It can also provide authentication, but its typically only used to
authenticate the identity of the web server to the client (via CA
trust chains). It is capable of authenticating the client identity to the
server, but most web servers are not set up for that. HTTPS can provide:
However, HTTPS cannot provide:
So, HTTPS does a good job of
providing strong enough encryption and server identity authentication to the
client. It’s also capable of providing client identity authentication to the
server. The problem is that it is a
“point-to-point” security, which doesn’t allow intermediaries to act on the
data, and requires trust between the HTTPS end-point and the location of the
application being secured.
1) Limitation #1:
End-to-End
HTTPS runs from HTTP client to HTTP server. It’s likely, however, that those are not
the end-points of the application. The encryption stops at the web server, while
the transaction continues on into the application server and database. Because
HTTPS does not provide authorization and encryption to the end-points of the
transaction, you must be able to trust the applications attached to the HTTP
end-points instead. (Otherwise, the server application could receive rogue
messages, claiming to come from trusted HTTP servers).
2) Limitation
#2: Protocol Translation
Because HTTPS does not run all the way to
the “end-points” of the transaction, the protocol must be translated, perhaps
into CORBA/IIOP or SQL*Net, as the application traverses the rest of the
pipes. Authentication,
identification, and confidentiality stop at the HTTP/S end points.
3)
Limitation #3: Signature and Non-Repudiation
Because the protocol
does not extend all the way into the database, it cannot provide an audit
trail. The web server (the
end-point of the encryption) can provide a log file, but not one robust enough
to use for non-repudiation. It does
not provide a signature that can be used for non-repudiation.
4)
Limitation #4: Element-wise Encryption
HTTPS encrypts
everything. For the message to be
routed through an intermediary, however, it must be decrypted in its entirety,
then re-encrypted for the next “hop” in the route. This limits the ability to
route XML messages via HTTPS, as it is “all or nothing” encryption that exposes
too much to intermediaries. Intermediary applications should only be able to
decrypt the portion relevant for their step of the processing. A good example of
this need is a credit-card number, which you only want to expose to the credit
clearinghouse, but not to the merchant [5]
C. HTTP
Basic Authentication is not Strong Enough
Most web applications
accept user authentication via HTTP basic or form authentication. For applications attempting to use the
same web servers to access web services, however, this presents a problem. The client applications must record the
userid and password for accessing the web service in their application code. If
the client application code is compromised, a malicious user could use that
recorded information to gain unauthorized access to the web service. Therefore, traditional user-oriented
authentication techniques are not strong enough when the client is an
application.
IV. Security Solutions
There are a number of
new standards that can be applied to web services and XML to provide security.
This section will address the areas of authentication, authorization,
identification, integrity, confidentiality, auditing, and non-repudiation. As these solutions are presented, we’ll
start with a simple SOAP envelope, and add security to it as we go. This first example is just a simple SOAP
message requesting an order for 2 books from amazon.com.
Example 1: A simple SOAP request, complete with envelope, header, and body
(01) <?xml version="1.0"
encoding="utf-8"?>
(02) <S:Envelope
xmlns:S="http://www.w3.org/2001/12/soap-envelope">
(03)
<S:Header>
(04) <!-- Later, we’ll put our
security stuff in here -->
(05)
</S:Header>
(06)
<S:Body>
(07)
<m:PlaceOrder
xmlns:m="http://www.amazon.com/soap">
(08)
<m:ISBN>0618134700</m:ISBN>
(09)
<m:Quantity>2</m:Quantity>
(10)
<m:CustomerNumber>ENJ-32423-CCNK</m:CustomerNumber>
(11)
<m:CreditCardNumber>4121883253447883</m:CreditCardNumber>
(12)
<m:CreditCardExp>06/06/2004</m:CreditCardExp>
(13)
</m:PlaceOrder>
(14)
</S:Body>
(15)
</S:Envelope>
A. Standards to Enable Integrity,
Authentication, and Confidentiality of Web
Services
Two
elements that are essential to securing web services are strong authentication
and confidentiality (via encryption).
There are three SOAP-oriented XML standards that address these
areas.
1)
WS-Security
The Web Services Security Specification (WS-Security)
standard provides a framework for securing SOAP messages. It describes how to exchange signed and
encrypted messages in a SOAP environment.
It does this by providing extensions to SOAP (by way of new XML tags and
structures). It can use PKI,
Kerberos,
Basic/Digest authentication, and SSL to provide the security.
WS-Security provides a framework that supports the concept of an intermediary. It allows the participants to define a security context between a requester and a web service - with an intermediary between them, or to define two separate contexts, one between the requester and the intermediary, and another between the intermediary and the web service.
Figure 1: Security contexts in
WS-Security (copied from [4]).
WS-Security defines a security
header in the SOAP message, that allows you to attach credentials (such as a
Kerberos ticket), along with a signature.
This header can be tagged with the SOAP mustUnderstand
attribute to “force” the receiving web service to either handle the security
header or reject the request altogether.
The payload (or portions
thereof) can be encrypted and placed in the SOAP envelope, provided the binary
output is converted to a textual format for transmission via XML. It also allows
the requester to submit a claim. A claim
is a statement that a client makes.
Examples are “name”, “identity”, “key”, “group”, “privilege”,
etc.
The following example (example 2 below) shows a
Security header (enclosed within the tags <wsse:Security>) inserted into a
SOAP envelope. It includes an x509 certificate enclosed within the
<wsse:BinarySecurityToken> tags.
The sender of this message is making a claim that they can be
identified by the x509 certificate represented within the
<wsse:BinarySecurityToken> tag.
Later, we’ll make use of that certificate by signing the
request.
Each namespace refers to a web services or XML specification that will be discussed further in this paper. This example is taken from the Web Services Security Extensions specification [6], with some modifications.
Example 2: A SOAP envelope with an X.509 certificate enclosed in the header
(01) <?xml version="1.0"
encoding="utf-8"?>
(02) <S:Envelope
xmlns:S="http://www.w3.org/2001/12/soap-envelope"
(03)
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"
(04)
<S:Header>
(05) <wsse:Security>
(06) <wsse:BinarySecurityToken
(07) ValueType="wsse:X509v3"
(08) EncodingType="wsse:Base64Binary"
(09) Id="X509Token">
(10) MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
(11) </wsse:BinarySecurityToken>
(12) </wsse:Security>
(13)
</S:Header>
(14)
<S:Body>
(15)
<m:PlaceOrder
xmlns:m="http://www.amazon.com/soap">
(16)
<m:ISBN>0618134700</m:ISBN>
(17)
<m:Quantity>2</m:Quantity>
(18)
<m:CustomerNumber>ENJ-32423-CCNK</m:CustomerNumber>
(19)
<m:CreditCardNumber>4121883253447883</m:CreditCardNumber>
(20)
<m:CreditCardExp>06/06/2004</m:CreditCardExp>
(22)
</S:Body>
(23) </S:Envelope>
Note that the body of the
message contains only a simple request to place an order for 2 books. The rest
of the message is devoted entirely to the SOAP header, which is entirely
security information to support this request. WS-Security encapsulates two other
important specifications that enable the authentication and encryption. These
are discussed below.
2) XML Digital
Signatures
The ability to authenticate a SOAP message is
vital to web services, especially if they become vital resources, as database
resources are today. Comparatively,
this is not a trivial task. Consider that authentication normally expects the
credentials of a single user, not another system. In client/server systems, this often
means a “pop-up” dialog box or a form to fill in. Other systems offer a command-line
prompt for user id and password.
Web-based systems prompt for HTTP basic authentication, digest
authentication, or form-based authentication. Web services, because they act more
autonomously, need stronger authentication mechanisms that can be placed
directly into XML messages.
The
SOAP digital signature specification [7] provides message
integrity (by signing a portion of the message that can be verified to see if
it’s been altered), and message authentication (by checking the signature to
ensure it came from a trusted source) [10]. Using digital signatures, the message
sender takes a portion of the message (or more likely, the entire payload of the
message – in this case, the whole body of the SOAP request), generates a digest
(hash) of the data, and signs the message with its private key (I say “its private key” instead of “his
private key” because the sender of the message is another application, not a
human being.) In the following example, I’ve added a reference to the XML
digital signatures namespace (“ds”) on line 04, and have added the following
signature information:
You’ll note that the message
digest and the signature value are plain characters. That’s because this specification calls
for the encoding of the binary data using Base 64 encoding, so that it can be
transported within an XML message.
You’ll also note that I’ve shortened the values to make it easier to read
the message. In reality, the digest and signature would take several lines
each.
Now that you can see where the
signature and message digest are, let’s go over the meaning of some of the other
digital signature elements, and why they’re
present:
KeyInfo
(lines 34-38): The last thing to note is the
<ds:KeyInfo> block. This block denotes the public key of the signer.
Note that line 36 references the URI of the “SecurityToken” (which is the
public key) that was defined in the <wsse:BinarySecurityToken>
block in
lines 07-12. It explicitly refers to the id on line
10.
Example 3: SOAP envelope with XML encoded digital signature using XML DSig
(01) <?xml version="1.0"
encoding="utf-8"?>
(02) <S:Envelope
xmlns:S="http://www.w3.org/2001/12/soap-envelope"
(03)
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"
(04)
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>
(05)
<S:Header>
(06)
<wsse:Security>
(07)
<wsse:BinarySecurityToken
(08)
ValueType="wsse:X509v3"
(09)
EncodingType="wsse:Base64Binary"
(10)
Id="X509Token">
(11)
MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
(12)
</wsse:BinarySecurityToken>
(13)
<ds:Signature>
(14)
<ds:SignedInfo>
(15)
<ds:CanonicalizationMethod
Algorithm=
(16)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(17)
<ds:SignatureMethod Algorithm=
(18)
"http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(19)
<ds:Reference>
(20)
<ds:Transforms>
(21)
<ds:Transform
Algorithm=
(22)
"http://...#RoutingTransform"/>
(23)
<ds:Transform Algorithm=
(24)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(25)
</ds:Transforms>
(26)
<ds:DigestMethod Algorithm=
(27)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(28)
<ds:DigestValue>EULddytSo1...</ds:DigestValue>
(29)
</ds:Reference>
(30) </ds:SignedInfo>
(31)
<ds:SignatureValue>
(32)
BL8jdfToEb1l/vXcMZNNjPOV...
(33)
</ds:SignatureValue>
(34)
<ds:KeyInfo>
(35)
<wsse:SecurityTokenReference>
(36)
<wsse:Reference
URI="#X509Token"/>
(37)
</wsse:SecurityTokenReference>
(38)
</ds:KeyInfo>
(39)
</ds:Signature>
(40)
</wsse:Security>
(41)
</S:Header>
(42)
<S:Body>
(43)
<m:PlaceOrder
xmlns:m="http://www.amazon.com/soap">
(44) <m:ISBN>0618134700</m:ISBN>
(45)
<m:Quantity>2</m:Quantity>
(46)
<m:CustomerNumber>ENJ-32423-CCNK</m:CustomerNumber>
(47)
<m:CreditCardNumber>4121883253447883</m:CreditCardNumber>
(48)
<m:CreditCardExp>06/06/2004</m:CreditCardExp>
(50)
</S:Body>
(51) </S:Envelope>
3) XML
Encryption
XML encryption allows the
message sender to protect the confidentiality of portions of the message,
allowing that portion to be understood only by an intended recipient. A common
example of this is a credit card number. A sender may route the SOAP message to
a web service by way of a credit clearinghouse, who plucks out the credit card
number, processes it, and routes the message to the destination web service. In
this example, we don’t want to expose that credit card number to anyone but the
credit clearinghouse.
XML encryption works by allowing the sender to specify which part of the body is encrypted, referencing the keys with which it was encrypted. As you can see above, I’ve been transmitting the credit card number in plain-text all along. Now let’s encrypt that credit card number:
Example 4: SOAP envelope
with an encrypted element using XENC
(01) <?xml version="1.0"
encoding="utf-8"?>
(02) <S:Envelope
xmlns:S="http://www.w3.org/2001/12/soap-envelope"
(03)
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"
(04)
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
(05)
xmlns:xenc=”http://www.w3.org/2001/04/xmlenc#”>
(05)
<S:Header>
(06)
<wsse:Security>
(07)
<wsse:BinarySecurityToken
(08)
ValueType="wsse:X509v3"
(09)
EncodingType="wsse:Base64Binary"
(10)
Id="X509Token">
(11)
MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
(12)
</wsse:BinarySecurityToken>
(13)
<ds:Signature>
(14)
<ds:SignedInfo>
(15)
<ds:CanonicalizationMethod Algorithm=
(16)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(17)
<ds:SignatureMethod Algorithm=
(18)
"http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(19)
<ds:Reference>
(20)
<ds:Transforms>
(21)
<ds:Transform Algorithm=
(22)
"http://...#RoutingTransform"/>
(23)
<ds:Transform
Algorithm=
(24)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(25)
</ds:Transforms>
(26)
<ds:DigestMethod Algorithm=
(27)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(28)
<ds:DigestValue>EULddytSo1...</ds:DigestValue>
(29)
</ds:Reference>
(30)
</ds:SignedInfo>
(31)
<ds:SignatureValue>
(32)
BL8jdfToEb1l/vXcMZNNjPOV...
(33)
</ds:SignatureValue>
(34)
<ds:KeyInfo>
(35)
<wsse:SecurityTokenReference>
(36)
<wsse:Reference URI="#X509Token"/>
(37)
</wsse:SecurityTokenReference>
(38)
</ds:KeyInfo>
(39)
</ds:Signature>
(40)
<xenc:ReferenceList>
(41)
<xenc:DataReference
URI=”#cardnum”/>
(42)
</xenc:ReferenceList>
(43)
</wsse:Security>
(44)
</S:Header>
(45)
<S:Body>
(43) <m:PlaceOrder
xmlns:m="http://www.amazon.com/soap">
(44)
<m:ISBN>0618134700</m:ISBN>
(45)
<m:Quantity>2</m:Quantity>
(46)
<m:CustomerNumber>ENJ-32423-CCNK</m:CustomerNumber>
(47)
<xenc:EncryptedData
Id=”cardnum”>
(48)
<ds:KeyInfo>
(49)
<ds:KeyName>CN=iTransact Inc.,
C=US</ds:KeyName>
(50)
</ds:KeyInfo>
(51)
<xenc:CipherData>
(52)
<xenc:CipherValue>Xd57Sui8/9eVfh...</xenc:CipherValue>
(53)
</xenc:CipherData>
(54)
</xenc:EncryptedData>
(55)
<m:CreditCardExp>06/06/2004</m:CreditCardExp>
(56)
</m:PlaceOrder>
(57)
</S:Body>
(58) </S:Envelope>
In this example, we’ve replaced
the plain-text credit card number with an encrypted data element enclosed in the
<xenc:EncryptedData> tags on lines 47 – 54. Here is the meaning of the
elements:
B. Standards to Enable
Authorization for Web Services
There are
two standards that enable authorization in web services: Security Assertions
Markup Language (SAML), and XML for Access Control Lists (XACL).
1) Security Assertions Markup
Language
It may not be obvious at first, but one key aspect of web services is the concept of single sign-on. The idea is that once the user has authenticated once, an application (or another web service) can forward that user’s credentials to another web service and request action on the user’s behalf. For this to work, we need a method for encoding the “assertion” by one application that it has authenticated the user’s credentials, allowing it to pass those credentials securely. An assertion is a declaration of facts (statements) about a subject (according to some SAML authority). Assertions can also be digitally signed, to prove that they came from a trusted source [12].
In addition, we need the ability to describe what parts of an application the user is authorized to access. SAML enables applications (web services) to exchange identity and entitlement information with each other [11]. SAML works by exchanging “assertions”, which confirm information about a user’s authorization, authentication, or other information. These assertions are usually time-bound, and describe events that have already occurred, such as, “This user has been successfully authenticated”, or “This application is authorized to take this action.” Here’s an example SAML authentication assertion, taken directly from [12]. This assertion says, “I authenticated mnystrom on www.cisco.com via password at 10:02AM on March 21st, 2002.”
Example 5: SAML
authentication assertion
(02) MajorVersion=”1”
MinorVersion=”0”
(03) AssertionID=”128.9.167.32.12345678”
(04) Issuer=”Cisco
Systems, Inc.”
(05)
IssueInstant=”2002-03-21T10:02:00Z”>
(06)
<saml:Conditions NotBefore=”2002-03-21T10:02:00Z”
NotAfter=”2002-03-21T10:07:00Z” />
(07)
<saml:AuthenticationStatement
(08)
AuthenticationMethod=”password”
(09)
AuthenticationInstant=”2002-03-21T10:02:00Z”>
(10)
<saml:Subject>
(11)
<saml:NameIdentifier SecurityDomain=”www.cisco.com” Name=”mnystrom”
/>
(12)
</saml:Subject>
(13) </saml:AuthenticationStatement>
Central to SAML is the concept
of an “issuing authority”. An
issuing authority is a central service responsible for authenticating and
authorizing users or applications.
This can be accomplished by using federated security service providers
(such as Microsoft’s Passport service), using a private 3rd party
security service provider (such as American Express), or setting up your own
private issuing authority within your own
domain.
Figure 2: SAML topography (taken
from here).
2) XML for Access Control Lists
(XACL)
It’s not what you think – this
isn’t a way to set up ACLs on network routers using XML. Instead, XACL allows you to hide or
expose certain portions of an XML document from users, based on their
roles. The idea is simple, in
addition to the XML document you want to protect, define an extra document that
references the original, and constrains access by role. [13].
Here’s an example of a simple XML document for which we may want to restrict access to certain portions, taken from [14]:
Example 6: Simple XML
document as fodder for XACL policy
(01) <personnel_info>
(02)
<name>Johnson</name>
(03) <salary
currency=”USD”>200,000</salary>
(04) </personnel_info>
Example 7: XACL policy document
(01)
<policy>
(02)
<xacl>
(03)
<object
href=”/personnel_info/salary”/>
(04)
<rule>
(05)
<acl>
(06)
<subject>
(07)
<role>Manager</role>
(08)
</subject>
(09)
<action name=”read”
permission=”grant”/>
(09)
</acl>
(10)
</rule>
(11)
</xacl>
(12)
</policy>
This allows you to authorize
viewing of only certain portions of the document based upon the role of the
user. The usefulness seems dubious, since there are existing authorization
models in database systems and applications with which it must compete. However, it does provide a way to define
authorization via XML.
Conclusion
Web services
present a unique challenge to the web.
They offer the ability to integrate and automate much of the e-commerce
that is currently conducted “manually” (consumer to business.) They leverage the simplicity and
ubiquity of HTTP and XML to allow new kinds of interactions between
applications. However, the
simplicity is a double-edged sword, as web services place more sensitive and
critical B2B transactions through the channels designed only for user
transactions.
WS-Security offers
a framework for strong authentication and encryption, while SAML and XACL
provide strong authorization.
Non-repudiation and auditing (via logging) can be provided by existing
web servers and application servers.
These techniques provide a means
to secure web services. They can
become effective as they are absorbed into application and web servers, so that
application developers can harness their power without being hindered by their
complexity. Tools from vendors such
as Netegrity (http://www.netegrity.com/), and Oblix (http://www.oblix.com/) offer solutions for
implementing these standards.
References
[1] D. Box, D.
Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, and
D. Winer. (2000, May 8).
Simple Object Access Protocol (SOAP) 1.1. W3C Standard. [Online]. Available at http://www.w3c.org/TR/SOAP.
[2] Netscape Corporation. (1998,
October 10). Netscape DevEdge. [Online]. Available at http://developer.netscape.com/docs/manuals/security/sslin/index.htm
[3]
http://www.faqs.org/rfcs/rfc2617.html
[4]
Anthony Nadalin and Nataraj
Nagaratnam. (May 2002). Securing Web Services. Presented at IBM DeveloperWorks Live!
2002.
[5] Maryann Hondo, Martin W.
Sachs, Peter Brittenham. (May 2002).
Web Services Security Metadata.
Presented at IBM DeveloperWorks Live! 2002.
[6] Microsoft, IBM, Verisign
(April 2002). IBM
developerWorks. [Online]. Available at http://www-106.ibm.com/developerworks/library/ws-secure
[7] A. Brown, B. Fox, S. Hada, B. LaMaccia, H. Maruyama.
(2001, February 6). SOAP Security
Extensions: Digital Signature. W3C Note.
[Online]. Available at http://www.w3.org/TR/SOAP-dsig/
[8] D. Eastlake, J. Reagle. (2002, March 4). XML Encryption Syntax
and Processing. W3C Candidate
Recommendation. [Online]. Available at http://www.w3.org/TR/xmlenc-core/
[9] J. Boyer. (2001, March 15). Canonical XML, Version 1.0. W3C
Recommendation. [Online]. Available
at http://www.w3.org/TR/2001/REC-xml-c14n-20010315
[10] M. Bartel, J. Boyer, B.
Fox, E. Simon. (2000, October
31). XML-Signature Syntax and
Processing. W3C Candidate
Recommendation. [Online]. Available at http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/
[11]
J. Byous. (2002, May 9). Single Sign-on Simplicity
with SAML. Java Developer Connection. [Online}. Available at: http://java.sun.com/features/2002/05/single-signon.html
[12] J. Rouault. (2002, January 18). Introduction to
SAML. [Online]. Available at http://www.simc-inc.org/archive0002/February02/devwed1015_rouault.pdf
[13] M. Kudo, S. Hada. (2000, October 24). XML Access Control.
Proposal to W3C. [Online]. Available at http://www.trl.ibm.com/projects/xml/xacl/xmlac-proposal.html
[14] IBM (2001, August 31). XACL Simple Example. [Online]. Available at http://www.trl.ibm.com/projects/xml/xss4j/docs/xacl-ex-simple1.html