Martin G. Nystrom
Graduate Programs, North Carolina State University
E-mail: mnystrom@cisco.com
Abstract
Armed with simple tools, businesses are using web services to bring together
disparate, network-separated applications. Due to the criticality and
sensitivity of the data, however, securing the data and respective applications
takes on growing importance. The first standards emerging for web services only
addressed the interaction, without addressing encryption, authentication, or
authorization. This paper seeks to explain some of the history and promise of
web services, the problems they present, and techniques for securing them. It
will cover emerging standards for web services security in the areas of
encryption, authentication and signing, and authorization. Standards under the
banner of WS-Security receive the most attention.
I. Introduction
The web services programming model is making it easier for businesses to conduct
electronic commerce with one another. It does so by using well-accepted
protocols such as XML and HTTP to represent the entire interaction in plain
text. This technique is often heralded as a great step forward over
traditionally complex models such as CORBA, DCE, and EDI, since it simply places
a new protocol on the already pervasive HTTP “pipes”. It is because of the
simplicity and pervasiveness of the web services model that effort must be
placed upon securing them, before relying on these new applications to exchange
critical and confidential information. This paper provides an overview of the
emerging standards and techniques for securing web services.
II. Background
A. XML
XML emerged in the late 1990s as a very simple, textual format for both
holding and describing information. Its self-describing format makes it perfect
for consumption by software applications. It’s also easy to transport, since it
can easily flow over HTTP. XML is like “machine consumable” HTML: both were
designed to present information, both of them over HTTP. Standards for sharing
data via XML have solidified in recent years with the advent of XML
namespaces and
XML Schema. These standards have provided a standard representation for
common data types such as strings, integers, etc. They also make it easy to
build an entirely new vocabulary upon the foundation of simpler types. Because
of its simplicity, and helped along by these foundational standards, XML has
become a very attractive tool for representing data for exchange between
applications.
B. SOAP
Simple Object Access Protocol (SOAP) emerged as a technique for making
remote calls between applications in the middle of 2000. It was brought to
W3C by Microsoft, IBM, UserLand, and DevelopMentor. SOAP defined a textual
envelope for carrying the message, rules for encoding the messages and faults,
and rules for encoding remote procedure calls (RPCs)
[1]. (See
example 1 for a sample SOAP envelope.) Because SOAP is textual (it uses XML
to encode everything), it can be used as a wire protocol over any transport you
wish. That said, because SOAP is attractive as a tool for combining
heterogeneous applications (using such tools as Java, Perl, and .Net), HTTP
makes a good “common denominator” transfer protocol. Technically, SOAP can be
used with CORBA, MOM, SMTP, and other transfer protocols, but HTTP has become
the simplest and most pervasive backbone for SOAP messages. SOAP has become the
de facto language of web services. Because of that, I will refer to SOAP when
discussing web services throughout this paper.
C. SSL and HTTPS
Secure Sockets Layer (SSL) was developed by Netscape and is now used by all web
servers and browsers as tool for authentication and encryption. It runs “on top
of” TCP/IP but “underneath” transports such as HTTP and LDAP
[2]. HTTP is run over SSL to create what is commonly called “HTTPS”.
Normally, HTTPS is used to validate the identity of the server to the client
(via a chain of trusted certificates), and provides end-to-end encryption for
the HTTP protocol. HTTPS can also provide client authentication, but HTTP basic
authentication (explanation directly below) is normally used for that. HTTPS
is often used to provide confidentiality (via strong encryption) for web
services, but it’s not a complete solution to the problem, as we shall see later
in this paper.
D. HTTP
Basic Authentication
Basic authentication is often used to provide userid/password authorization to
web resources. All web servers provide a means for protecting resources using
basic authentication. Using this technique, the web server checks to see if the
user has sent authentication credentials when trying to access a protected
resource. If the user has not logged in (indicated by the presence of base-64
encoded credentials in the HTTP header), he is challenged with a login dialog.
[3] Basic authentication is not considered strong authentication, because
it’s trivial to un-encode the username and password (Base64 encoding is not
considered encryption, because there’s no secret key). HTTP digest
authentication is also available, and is more secure than basic authentication,
but it is not widely used, and support in browsers is inconsistent.
III. Security Concerns
The web services model, because it leverages tools and protocols designed for
user-to-server interaction, presents some unique problems for traditional
infrastructures.
A. Existing Firewalls
Firewalls are designed to protect networks by restricting connections to hosts
and ports. Firewalls are vital to enable external access to resources like your
company’s web server or mail server. For example, a firewall at Nitram
Techologies might set up their ports to allow connections from anywhere to:
www.nitram.com:80 (normal web server traffic)
www.nitram.com:443 (secure web server traffic)
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:
Identification
via client
certificates
Authentication
by checking the signature of the data, using the
public key in the client certificate
Integrity
by validating the data against a message digest
to ensure it’s not been tampered with in transit
Confidentiality
by encrypting the traffic using a key negotiated
during the handshake.
However,
HTTPS cannot provide:
Authorization
– it has no vehicle for checking what this user
is attempting to do and selectively allowing/disallowing the operation
Auditing
– it does not log who attempted to authenticate,
who was denied, etc.
Non-repudiation
– it does not provide a way for sender to prove
that the receiver received it, and vice-versa.
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>
(21) </m:PlaceOrder>
(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:
- The
digest of the object to be signed is contained in the <ds:DigestValue>
section on line 28. (It’s a hash of the data in the body, on lines 43-45).
The method for generating the digest is noted in the <ds:DigestMethod
Algorithm> section on lines 26 and 27. In this example, we used SHA1 as the
digest method. - The
signature value is contained in the <ds:SignatureValue> section enclosed
between lines 33 and 35.
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:
CanonicalizationMethod Algorithm
(lines 15-16): This is
necessary to enable the message receiver to reassemble the message from
message digests or encryption. The idea is that you should be able to make
sense of the message, placing the elements of the body back together
properly, after you decrypt it or un-digest it. The method you use for
“canonicalizing” the data is referenced in this tag. This is used along
with the <ds:Transforms> section on lines 20-25 to note pre-processing that
was applied to the content before it was digested
[10].
SignatureMethod Algorithm
(lines 17-18): This
allows the sender to specify what kind of cryptographic algorithm was used
when signing the message. In this case, it was RSAwithSHA1.
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>
(49) </m:PlaceOrder>
(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:
<ds:KeyInfo>
(between lines 48-50):
contains the key used to encrypt the data. Notice that the sender didn’t
use the same key with which it signed the data. Instead the sender signed
the request with a private key, so the message receiver can verify it with
the client app’s public key. To protect confidentiality, the sender
encrypts the data with the intermediary app’s public key (in this case,
“iTransact, Inc.”s public key certificate, named within the <ds:KeyName>
tag), so that it can only be decrypted with the intermediary’s private key.
<xenc:CipherData>
(between lines 51-53):
contains the encrypted data, which in our example is denoted by the
<xenc:CipherValue> tags.
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
(01) <saml: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>
Now, let’s
say that we want to restrict access to the salary node to only those
users with the role of “Manager”. We do this by setting a policy in the Access
Control Rules file, that looks like this:
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
0 comments:
Post a Comment