Web Services and SOAP
The actual definition of a Web service is a matter of some debate
because the world of Web services can extend from small closed
networks to global discovery services implemented using UDDI
(Universal Description, Discovery, and Integration). But at a
practical implementation level it is useful to think of a Web service
as any software service that can be defined using WSDL (Web Services
Description Language) and which uses SOAP for communication between a
requester and a listener. This communication uses SOAP as the
enveloping protocol.
Tools such as SOAP:Lite (www.soaplite.com) written by Paul
Kulchenko, or the IBM Web Services toolkit (http://alphaworks.ibm.com/tech/webservicestoolkit) allow for SOAP requests to be created
simply and easily.
SOAP listeners are offered in many products, including application
servers such as IBM WebSphere (SOAPConnect) and databases such as
Oracle 9i. Together, SOAP listeners and
SOAP requesters provide a simple means
of providing services to customers.
Web services allow organizations to expose software services to
customers, trading partners, and even the entire world, in a simple
fashion. SOAP is the ubiquitous Web services protocol and is designed
to be easy to use - which is why the S in SOAP stands for "Simple."
But this simplicity comes with a downside - because if security is
compromised, then the benefits of Web services are wasted.
The need for security in Web services is not only related to the
monetary value of goods or services that are being exchanged through
the service. More abstract items such as brand value and reputation
are at stake when security is compromised. In addition, a Web service
may allow an attacker to reach into a company's internal systems, and
this has the potential to be dangerous, whether the Web service is
commercial or not. The value of the systems and/or data that are
being exposed to the Internet therefore also has to be taken into
account. In short, security is a requirement for practically all Web
services. This article will look at how security applies to Web
services - beginning with technologies that carry over from the
browser-based Internet and then moving on to new initiatives specific
to Web services, such as SAML and SOAP-SEC.
New Risks
Although it may seem obvious, it's sometimes forgotten that Web
services make use of the same Web technologies that have suffered
many security compromises in the past. Web services don't necessarily
use the Web - indeed, SOAP can be sent over SMTP (i.e., e-mail) Sun's
definition of a Web service describes it as: "specific business
functionality exposed by a company, usually through an Internet
connection, for the purpose of providing a way for another company or
software program to use the service."
In practice, however, the vast majority of Web services rely on a Web
server. If improperly configured, Web servers are vulnerable to such
things as buffer overflow attacks or URL "button-pushing" attacks.
Buffer overflow attacks consist of a stream of text sent maliciously
to a Web server in order to load executable code into memory and
effectively hijack the Web server. "Button-pushing" URL attacks are
an effective way of probing for vulnerabilities in Web servers by
mischievously sending bogus data to Web applications.
Many best practice papers and security patches already exist for Web
servers. For example, Microsoft produced a guide to securing IIS 5.0
(the Web server for .NET) at www.microsoft.com/serviceproviders/whitepapers/securing_iis_whpaper.doc.
However, SOAP adds a new dimension to attacks on Web servers. In
addition to buffer overflow attacks against the Web server itself,
these attacks can now be directed through the Web server at the SOAP
engine. For example, if a Web service expects an XML document to
contain a 20-character text string as data
in an XML element, what happens if a 30-character text string is
sent? That's why it makes sense for an incoming document to be parsed
against an XML Schema,
run through a DOM or SAX parser, in order to check that it's valid.
The old maxim of CGI script authors - never trust your input - is
still valid for SOAP.
Past Security Measures
When Netscape introduced SSL (Secure Sockets Layer) in the Netscape
1.1 browser, back in March 1995, SSL established itself as the de
facto method for encrypting data between Web browsers and Web
servers. SSL creates a secure channel through which sensitive data,
such as credit card details, can pass. SSL uses digital certificates
to provide the transparent authentication of Web servers and,
optionally, Web browsers as well. Digital certificates store the
public key of a person or entity and bind this key to information
about that person, and to the issuer of the certificate. A public key
is used to encrypt data in such a way that only the holder of the
corresponding private key can decrypt the data - using an asymmetric
encryption algorithm. SSL uses the RSA asymmetrical encryption
algorithm as the means to create a secure "pipe" between the browser
and the Web server. After the SSL connection is established, the RC4R
algorithm is the preferred algorithm for encryption and decryption of
data, since it is faster than RSA.
After a number of early SSL vulnerabilities were addressed, SSL
proved itself to be dependable and secure. However it still relies on
careful implementation and as recently as September 2001 a
vulnerability was found in the SSL implementation contained in RSA
Security's BSAFE toolkit, that could allow an attacker to bypass SSL
client authentication, the process of determining whether someone or
something is, in fact, who or what it's declared to be. SSL provides
this capability through the use of digital certificates stored "at
the client" - i.e., with the Web browser.
Following the success of SSL for business-to-consumer (B2C)
transactions, the same technology was applied to business-to-business
(B2B) transactions. Initially this was focused on "marketplaces" - in
which a person manually keyed information into a Web site
for product procurement. More recently, it
was realized that the real value for B2B
e-commerce was for "lights-out" data traffic not involving Web
browsers at all. For over 15 years, electronic business documents
have been sent over EDI networks that are "fenced off" from the
Internet. However, these networks tend to be expensive, so it's
tempting to use the public Internet instead. XML-based Web services
encompass and surpass many of the capabilities of these
private EDI networks, especially in the area of interoperable
document types and service discovery. However, in order for Web
services to truly recreate the value of private networks on the
public Internet, communications confidentiality is required, along
with authorization and access control, communications integrity, and
an audit trail.
Digital Signatures
SSL provides the first item and a portion of the second - so let's
examine the rest...
SSL is found wanting in the area of audit trails. It's difficult to
prove that an SSL session occurred, or even to prove that a piece of
data has been received using SSL. This is where digital signatures
come into play: digital signatures use the same underlying technology
as encryption, but rather than hiding data from prying eyes, digital
signatures prove that a signatory did indeed sign a piece of data
(this is commonly called "non repudiation"). In addition, a digital
signature protects a document from tampering. This is one key
difference between a digital signature and a handwritten signature.
To quote EU Directive 1999/93/EC, a digital signature is "linked to
the data to which it relates in such a manner that any subsequent
change of the data is detectable."
A digital signature is an encrypted digest of a document. A digest is
obtained by passing a document through a hashing algorithm, which
produces a short string of bytes that's almost uniquely linked to
that document. This digest is then encrypted with the signer's
private key. Checking a digital signature involves recomputing the
digest from the document, decrypting the digest in the digital
signature using the signer's public key, and making sure that the two
digests match.
xml-dsig
XML Digital Signature (xml-dsig) is a joint initiative of the IEFT
(Internet Engineering Task Force) and the W3C (World Wide Web
Consortium). xml-dsig defines a means of rendering a digital
signature in XML. It's often mistakenly assumed that XML Digital
Signature is just for digitally signing XML documents, whereas in
fact it is for signing "any digital content," to quote the
specification at www.w3.org/Signature. xml-dsig brings the well-known
benefits of XML to digital signatures, making them human-readable,
easily parsed, platform independent, and generally more simple to
implement than preceding standards like PKCS#7. In addition, xml-dsig
defines a method for multiple documents to be referenced in one
signature, and mandates that information about the encryption
algorithms used is also signed.
An XML Signature may be "enveloped," in which case it's located in
source XML, "enveloping," in which case it wraps around the source
XML, or "external," in which case it's in a separate document from
the source XML. External XML Signatures may point to any URI on the
Internet.
As mentioned above, xml-dsig isn't just for signing XML. Nonetheless,
when XML in particular is being signed, certain considerations apply.
It's important that, if the signing decision depends on what the user
sees, then "sign what you see" is implemented. A user views an HTML
page to fill out a Web form, resulting in a SOAP message being
produced and digitally signed, and in this case it's important that
the visual information presented to the user is signed. That's
because the XML rendered as HTML may depend on fonts or inline
images, which make it very different from the underlying XML.
Digitally signing a SOAP message presents special requirements. Portions of the Header of a SOAP message may change when the message
is routed between Web services. If these are signed, then the
signature is guaranteed to break. An example of a volatile SOAP
Header element is the actor element, whose data changes when a SOAP
message is routed upstream to a further SOAP actor.
SOAP-SEC
There are two separate proposals that describe techniques for signing
a SOAP message. The first is SOAP-SEC, submitted to the W3C on
February 9, 2001, by IBM and Microsoft. SOAP-SEC defines a method of
signing SOAP 1.1 messages using a new header entry called
SOAP-SEC:Signature. Two existing SOAP header items are reused for
SOAP-SEC: "actor" to indicate the recipient of a header element, and
"mustUnderstand" to indicate whether or not an application must
attempt the validation of the enclosed XML Signature.
An example of a SOAP-SEC signed message is shown as Listing 1. Here
we can see that the XML Signature in the SOAP message is referencing
the signed data by using the "WhatWeAreSigning" ID. In addition, we
can see that a Canonicalization algorithm is used. Canonicalization
is needed for XML Signature because an XML document can change
slightly but remain as valid XML. Examples of changes to an XML
document include DOM processing, which may remove unnecessary white
space between elements, or simply the differences between line
endings between UNIX and Windows systems. Any of these seemingly
minor changes to a document invalidates its digital signature. Prior
to being signed, an XML document must therefore first be converted to
a canonical form by removing spaces between elements and any
platform-specific data.
WS-Security
On October 23, 2001, Microsoft produced a draft of a specification
called WS-Security. WS-Security defines XML elements called <credentials>, <integrity>, and <confidentiality>
that can be used in a SOAP message for, respectively, digital
certificates, digital signatures, and encrypted data. As such,
WS-Security is a much more detailed specification than SOAP-SEC and
encompasses more than just digital signatures. It remains to be seen
if WS-Security will replace SOAP-SEC.
SAML
Security Assertion Markup Language (SAML) is an OASIS (www.oasis-open.org) initiative that aims to define a standard way to
securely exchange authentication and authorization information for
Web services. Organizations may require that their Web services are
accessed only by authenticated users. This access to authenticated
users may well become as important in the future as access to
suppliers or markets.
SAML breaks down a bottleneck in access management by allowing users
to authenticate to one authentication service, and carry their
credentials to another service. There's no need for users to
reauthenticate in order to access further services. Similarly,
there's no special requirement for all users of a Web service to
authenticate in the same manner (e.g., by using only
username/password or using only client certificate). Until now,
access management and single sign-on products were limited to single
organizations and/or administrative domains. SAML extends these
products across the Internet by defining XML Schemas for assertions.
These assertions are sent as SOAP messages over HTTP, and refer to
decisions regarding authentication, attributes, and authorization.
To put this into context, Listing 2 gives an example of each type of
assertion. As the listing shows, assertion is used to indicate that
the user has proven their identity (i.e., authenticated) to a given
authentication authority, or security domain. In this case, a
password was used to authenticate. The assertion is created by the
authenticating security domain in order indicate to a second domain
that the user was authenticated. In addition, information about the
lifetime of the assertion is included in the "NotBefore" and
"NotAfter" elements. SAML uses XML Digital Signature to ensure that
this message is uniquely linked to the issuer, and so that any
changes to the message can be detected.
Listing 3 shows an example of an Attribute Assertion. This assertion
asserts an attribute of the user - in this case their
SubscriptionStatus. Again, XML Digital Signature can be used in order
to ensure that this message is uniquely linked to the issuer, and
cannot be changed without detection.
Finally, Listing 4 shows an Authorization Decision Assertion. This is
used to assert the result of a policy - in this case the permission
to access a Web page. Here we can see the Web page referenced in the
"Resource" element.
SAML 1.0 was expected to be submitted as a recommendation to OASIS on
March 1, 2002. Of the items deferred from SAML 1.0, the most notable
is Microsoft Passport integration. Microsoft Passport will most
likely be the most widely used authentication system on Earth.
Integration with Passport will be crucial to SAML's success beyond
being a system for linking access management products across
enterprises. The OASIS Security Services Technical Committee has
already committed to further development of SAML beyond version 1.0.
XACML
XACML (XML Access Control Markup Language), also developed by OASIS,
is a technology complementary to SAML that allows access control
policies to be expressed in XML. When a SAML assertion is received by
a Web service, the Web service sends a request to a SAML PDP (Policy
Decision Point), which checks an XACML policy via a PRP (Policy
Retrieval Point). The advantage of using XML for access control means
that policies from various access control products can be replicated
easily, using XACML as a common data format.
XML Encryption
XML Encryption is a proposal that is being developed by the W3C - see
www.w3.org/ Encryption. Just as XML Signature is more than just a
means to sign XML, XML encryption is more than just a means to
encrypt XML. It expresses meta-information about a signed digital
document, so that a processor of that document is aware of what
algorithms were used to encrypt the document.
XML Encryption allows for the encryption only of what must be kept
confidential, allowing a business systems to continue to use, as
before, the unencrypted data. Element names can be encrypted alone,
or with the data contained within them, or both. Sometimes it's
preferable to encrypt just the data itself, not the XML element
surrounding the data, because a schema or DTD contains information
about the name of the XML element that has been encrypted. This gives
an attacker a valuable clue to use in a brute-force decryption attack.
XML Encryption and XML Signature are used together when a document is
both signed and encrypted. For example, a SOAP message may be signed
using SOAP-SEC and also carry an encrypted attachment. In order to
check the signature of the data, the signed document must first be
decrypted by means of a transform.
This decryption transform is being proposed by the W3C at www.w3.org/TR/xmlenc-decrypt. The proposal notes that when a
document is signed first and then encrypted, the XML Signature
reveals the digest value of the signed resource. This is useful
information for an attacker who implements a guessing attack on the
plaintext data, especially since digest algorithms are suitably fast
for guessing attacks. In addition, it's noted that a signature over
encrypted data is not the same as a signature over the data prior to
encryption - recall the discussion above on "Sign what you see."
XKMS
The final protocol to consider is XKMS (XML Key Management Protocol).
XKMS isn't just a building block for secure Web services, it's also a
means of using Web services to simplify a number of complicated PKI
(public key infrastructure) protocols. As such, it is as much about
applying Web services to security as applying security to Web
services. XKMS incorporates X-KISS (XML Key Information Service
Specification), which provides an important component of Web services
security - namely a means to query the trustworthiness of a user's
digital certificate. A digital certificate can be registered with an
XKMS service using another subcomponent of XKMS - X-KRSS (XML Key
Registration Service Specification). XKMS has been submitted to the
W3C as a W3C Note - see www.w3.org/TR/xkms.
Combining Security Measures
UDDI has a number of unique security requirements, many of which may
be addressed by a combination of XML Digital Signature, SAML, and XACML. The UDDI v1 specification makes no mention of security, so
security for UDDI is presently a matter for debate. But one likely
scenario would be:
- The UDDI registry and service provider must authenticate one
another so that a third party cannot register services on behalf of
the genuine service provider.
- The UDDI registry must determine if the service provider has
authority to register its service. The act of publishing a service in
a UDDI directory may be protected by digital signatures and,
possibly, encryption, so that the service provider can't repudiate
the offering of the service; and "sniffers" can't determine details
of service.
Similarly, SAML and XACML allow the UDDI registry to determine if the
service requester has authority to find the service registered by the
service provider. Digital signatures and encryption can be used to
protect the authenticity, integrity, and confidentiality of exchanged
data. If the service requester is authorized to find the service, the
UDDI registry signs the WSDL that's returned to the service
requester. It may also encrypt the data if the service type is
intended to be kept confidential. In addition, any alteration to a
published WSDL interface is effectively a denial-of-service attack
because the published service can no longer be discovered. Therefore,
it's important that published WSDL interfaces are digitally signed.
Note that the digital signature on the WSDL would often be that of
the service provider, not the UDDI registry. The UDDI registry would
sign the SOAP message containing the WSDL sent back to the service
requester. This is an example of a signature over data which has
already been signed.
Conclusion
Many of the technologies discussed in this article remain works in
progress. XML Signature is closest to ratification, XML Encryption is
largely defined, but security for UDDI remains a matter for debate.
It seems certain that a combination of XML Signature, XML Encryption,
SAML, XAC ML, and XKMS will need to be used to secure Web services.
As Web services pass beyond the initial pilot and proof-of-concept
stage, security is vital for them to achieve the scale of mass
deployment that has been widely predicted.
Author Bio
Mark O'Neill is CTO of Vordel, where he oversees the development of
Vordel's technical strategy and product development in the areas of
XML and public key cryptography. Mark is a member of the OASIS
Security Services Technical Committee and an advisor to the XML.org
industry newsletter.
Mark.oneill@vordel.com
Focus on Security, by Mark O'Neill
WSJ Vol 02 Issue 03 - pg.27
Listing 1: SOAP message signed using SOAP-SEC
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<SOAP-SEC:Signature
xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12" SOAP-ENV:mustUnderstand="1">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<ds:Reference URI="#WhatWeAreSigning">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>erjwlewEWRewrfmpaeaesA=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>wfmSSasASFASqasf=...</ds:SignatureValue>
<ds:KeyInfo>
<ds:KeyName>Marko</ds:KeyName>
</ds:KeyInfo>
</ds:Signature>
</SOAP-SEC:Signature>
</SOAP-ENV:Header>
<SOAP-ENV:Body
xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12" SOAP-SEC:id="WhatWeAreSigning">
<StockOrder:buy xmlns:StockOrder="http://www.stockorder.com/Stock">
<StockOrder:symbol>SGP</StockOrder:symbol>
<StockOrder:quantity>2000</StockOrder:quantity>
<StockOrder:market>New York</StockOrder:market>
</order:buy>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Listing 2: SAML authentication assertion
<saml:Assertion
MajorVersion="1" MinorVersion="0"
AssertionID="312.5.32.2.6422421"
Issuer="Vordel"
IssueInstant="2002-01-05T13:32:00Z">
<saml:Conditions
NotBefore="2002-01-05T13:30:00Z"
NotAfter="2001-12-03T13:28:00Z" />
<saml:AuthenticationStatement
AuthenticationMethod="password"
AuthenticationInstant="2002-01-05T13:30:00Z">
<saml:Subject>
<saml:NameIdentifier
SecurityDomain="vordel.com"
Name="marko" />
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
Listing 3: SAML attribute assertion
<saml:Assertion É>
<saml:Conditions É/>
<saml:AttributeStatement>
<saml:Subject>
<saml:NameIdentifier
SecurityDomain="vordel.com"
Name="marko" />
</saml:Subject>
<saml:Attribute
AttributeName="SubscriptionStatus"
AttributeNamespace="http://vordel.com">
<saml:AttributeValue>
UpToDate
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
Listing 4: SAML authorization decision assertion
<saml:Assertion É>
<saml:Conditions É/>
<saml:AuthorizationStatement
Decision="Permit"
Resource="http://vordel.com/news/index.html">
<saml:Subject>
<saml:NameIdentifier
SecurityDomain="vordel.com"
Name="marko" />
</saml:Subject>
</saml:AuthorizationStatement>
</saml:Assertion>
All Rights Reserved
Copyright © 2004 SYS-CON Media, Inc.
E-mail:
info@sys-con.com
