Author: Jeffrey L. Vagle
are particularly vulnerable to breaches in security. The flow of
potentially sensitive data not only between machines, but between
enterprises and across untrusted networks, presents the need for
special attention to areas such as message confidentiality, message
integrity, authentication, and authorization. Additionally, since
Web services are well suited to business-to-business communications and
cooperation, there should be some way to enforce trust relationships
between business partners. Finally, Web services are used not
only by humans, but by other Web services as well. The high
degree of automation required for interaction between Web services
requires well-designed software architectures, preferably built upon
well-designed standards.Since Web services are designed to be
able to operate over HTTP, one can certainly employ HTTP-based security
mechanisms such as HTTP authentication and SSL/TLS.
However, the use of Web services is not limited to point-to-point SOAP message exchanges over
HTTP. Web service SOAP messages may follow a complex path between
multiple machines and trust domains, or they may be passed using
transport mechanisms other than HTTP. In either of these cases,
standard HTTP-based security measures may be inappropriate or
inadequate due to the fact that they were designed to support secure
point-to-point communication using HTTP at the transport level.
Recognizing these needs, various corporations and standards bodies
including the World Wide Web
Consortium (W3C), the Internet
Engineering Task Force (IETF), and the Organization for the
Advancement of Structured Information Standards (OASIS) have begun
to draft Web service security-related specifications, which are all at
varying levels of maturity. These specifications address such
needs as message confidentiality and integrity, security policy, and
distributed trust, as well as more advanced concepts such as enterprise
federation and security contexts.
The collection of standards
and specifications we present below is by no means exhaustive, but
instead concentrates on those that may be more important, relevant, and
potentially useful in the near term.
Foundations
Most
of the Web service security specifications depend on existing standards
in order to minimize any wheel reinvention. These foundations are
leveraged to provide message confidentiality, integrity, and
authentication.
X.509 — X.509 is shorthand for a set of standards describing X.509-based
public key infrastructure (PKI), maintained by the IETF.
Collectively, these specifications provide information necessary for
certificates, certificate revocation, and certificate management,
topics which we have discussed in previous articles (1, 2).
XML Signature — XML Signature is an
IETF/W3C standard that provides for embedding digital signatures within
XML documents (such as a SOAP message), a notion that we discussed
briefly in an earlier article. In addition to providing the usual benefits
of digital signatures, such as authentication, non-repudiation, and
message integrity, XML Signatures allow you to use the structure of the
XML document to sign selected portions of that document. This
feature is especially useful when an XML message gets passed around a
number of times, being signed at every step — you can verify the
history of the document by sorting through the sections of the document
that are relevant to the various entities involved.
XML
Signatures may be used to sign portions of a document in a number of
ways. Obviously, in order to verify a digital signature, the data
that was originally signed must be available to the verifier. The
XML Signature standard allows for some flexibility to achieve
this. If the data resides within the XML document, the signature
can exist as an XML sibling to the data in the document, as an XML
parent, or as an XML child of the data. If the data to be signed
does not reside within the XML document, the data may be referenced
from within the document as a URI within the XML Signature itself.
XML
Encryption — Although SSL/TLS provide transport-level
encryption services to HTTP, for the reasons discussed above, Web
services often require a greater degree of flexibility and
functionality. XML
Encryption provides message-level encryption with the added
flexibility of selective encryption, multi-party encryption, and better
non-repudiation functionality, all of which can be used to augment an
existing SSL/TLS infrastructure’s security.
XML Encryption can
encrypt both text and binary data within an XML document, and like the
XML Signature specification, can encipher portions of an XML document,
including both XML elements or simply the data therein.
SAML — The
Security Assertion Markup Language (SAML) is a standard being developed
under the OASIS SAML Technical Committee. SAML uses XML to
allow security information (assertions) to be expressed as part of the
XML message itself. These security assertions are about subjects
— humans, computers, or organizations — and their role in some
security domain. Assertions are made by SAML authorities: trusted
entities with control over authentication, authorization, attributes,
and policies within a domain.
Security assertions
follow common-sense rules that we all employ on a regular basis.
For example, when issued an identification card by your employer, your
employer is asserting that you
have certain access rights and privileges within the company.
Here, the company is acting as the SAML authority: as the trusted
entity within this particular security domain (the corporation), it can
grant and revoke rights and privileges based on current company
policy.
Web Service Security specifications
Much like the Web services that they are designed
to protect, the Web Service Security specifications leverage open,
extensible technologies like XML and SOAP to maximize usage flexibility
through combination and composition. The WS-Security
specification provides a foundation upon which the other standards can
be built. When used together, these specifications can be applied
to a wide variety of security models and architectures.
WS-Security — The
WS-Security specification is maintained under OASIS and describes
enhancements to the SOAP message architecture to provide message
confidentiality, message integrity, and authentication. As a
foundation for other Web service security specifications, it leverages
existing standards such as X.509, XML Signature, and XML Encryption,
defining constructs for self-contained security information within SOAP
messages.
In addition, WS-Security defines a framework
for security credential and encryption information sharing through
security tokens through the UsernameToken and BinarySecurityToken
extensions.
WS-SecurityPolicy — WS-
SecurityPolicy has been published jointly by a collection of
corporations as a public specification. WS-SecurityPolicy is
considered an addendum to the WS-Security specification, and allows for
the definition of a Web service’s policies and security
requirements.
WS-Trust — The WS-Trust specification also builds upon the WS-Security
foundation, and defines the use of security tokens to manage
distributed trust. This is especially useful for the ad hoc use
of Web services. Before establishing communication, all parties
must exchange security credential information, and must then decide
whether or not to trust that information. This specification
provides extensions to WS-Security to allow for the establishment of
distributed trust relationships in a Web services environment.
WS-SecureConversation — Using WS-Security and
WS-Trust as building blocks, the WS-SecureConversation specification defines extensions
which allow security context management and session-key
derivation. A security context of a session is that session’s
authentication state along with other security information that has
been generated as part of that session, such as session keys. By
using the WS-SecureConversation framework in conjunction with
WS-Security and WS-Trust, users can employ secure messaging across
multiple message exchanges.
WS-Federation — Since Web services
may be designed to be deployed among multiple organizations, involving
multiple trust realms, there is a need to maintain the usual security
requirements like authentication, identification, and authorization
across these boundaries. The WS-Federation specification addresses this need by defining a
framework which enables sharing relevant information regarding
authentication, authorization, identity, and trust between security
realms. Again, WS-Federation is meant to be considered in tandem
with the WS-Security and WS-Trust specifications.
Category:
- Web Development
