An Overview of the WS-Security Framework
by Thomas Erl

As the complexity and sophistication of application and business logic within Web services increases, so does the risk associated with putting a corporation’s business intelligence “out there.” An increased level of service-oriented application functionality leads to more integration opportunities with external business partners. The purpose of this article is to create an awareness of the many aspects of Web services security, with an emphasis on the WS-Security framework.

While the security framework established by the many specifications that provide standards for XML and Web services is relatively new, most of the principles behind these standards are not. The fundamental characteristics of a primitive security architecture are just as relevant to service-oriented environments as they are to traditional distributed applications.

Here’s a quick recap of these established concepts:

Identification

The recipient of a message needs to be able to identify the sender.


View Larger Image

Authentication

The recipient of a message needs to verify that the claimed identity of the sender is valid.


View Larger Image

Authorization

The recipient of a message needs to determine the level of the sender’s security clearance. This can relate to which operations or which data the sender is granted access to.


View Larger Image

Integrity

A message remains unaltered during transmission, up until actual delivery.


View Larger Image

Confidentiality

The contents of a message cannot be viewed while in transit, except by authorized services.


View Larger Image

To understand how service-oriented architectures deal with these security requirements, we need to take a look at the ever-evolving world of Web services and XML security specifications. Below are some of the more important standards, organized by how they relate to the fore-mentioned security requirements.

Identification

Authentication

Authorization
WS-Security Framework

Extensible Access Control Markup Language (XACML)

Extensible Rights Markup Language (XrML)

XML Key Management (XKMS)

Security Assertion Markup Language (SAML)

.NET Passport
Confidentiality WS-Security Framework

XML-Encryption

Secure Sockets Layer (SSL)
Integrity WS-Security Framework

XML-Digital Signatures

These and other specifications form building blocks that can be assembled to create service-oriented security (SOS) models. Let’s take a brief look at each one.


XML Key Management (XKMS)

XML Key Management establishes a standard means of obtaining and managing public keys. Even though XKMS is compatible with a number of public key infrastructure (PKI) technologies, it does not require any of them, and removes the need for integrating proprietary PKI products.

The XML Key Management specification consists of two complementary standards: the XML Key Registration Service and the XML Key Information Service specifications. Together, they allow for the integration of a number of security technologies, including digital signatures, certificates, and revocation status checking. For instance, XKMS can enlist XML-Digital Signatures to protect the integrity of XML document content.


Extensible Access Control Markup Language (XACML) and Extensible Rights Markup Language (XrML)

The XACML specification consists of two related vocabularies: one for access control and one that defines a vocabulary for request and response exchanges. Through these languages, the creation of fine-grained security policies is possible.

It is important not to confuse XACML with the WS-Policy specification, which also can be used to define policies, and is considered part of the WS-Security framework. An additional specification that may be relevant to your environment, if you transport files with different digital formats, is the Extensible Rights Markup Language (XrML).


Security Assertion Markup Language (SAML) and .NET Passport

Single sign-on technologies help address an administration problem that has emerged when an enterprise environment consists of applications that independently control user access lists. If a single sign-on system is not already in place, adding Web services can contribute to the decentralized proliferation of user credentials. By opening up new integration channels, more users may be required to access applications. This can lead to an ever-increasing maintenance effort.

Popular technologies for single sign-on include the Security Assertion Markup Language (SAML) and the .NET Passport. SAML provides mechanisms for both authentication and authorization processes. Both request and response message formats are defined to facilitate the transmission of necessary credentials within a Web service activity. Microsoft’s .NET Passport is a competing technology, and relies on proprietary protocols for handling authentication. It also introduces a centralized management system for user credentials, which differs from SAML’s decentralized approach. Interoperability options between the two technologies do exist, and continue to improve.


XML-Encryption and XML-Digital Signatures

These two key specifications protect the actual content within XML documents.

The XML-Encryption specification contains a standard model for encrypting both binary and textual data, as well as a means of communicating information essential for recipients to decrypt the contents of received messages.

XML-Digital Signatures establishes a standardized format for representing digital signature data. Digital signatures establish credibility within a message, as they assure the recipient that the message was in fact transmitted by the expected partner service. It also provides a means of communicating that the message contents were not altered in transit, as well as support for standard non-repudiation. As with the XML-Encryption standard, XML-Digital Signature also supports binary and textual data.


Secure Sockets Layer (SSL)

A common response to addressing WS-Security requirements is: “we’ll just encrypt it with SSL.” Many assume that this is a valid security measure, because they associate the Internet-based communication between Web services with the traditional interaction between a browser and a Web server.

The Secure Sockets Layer (SSL) technology enables transport-level security. Accessing a secured site using a browser is a fairly safe procedure, when communication is encrypted. That is because the connection is exclusive to the client browser and the Web server that acts as the gateway to internally hosted application logic.

Once a Web service transmits a message it does not always know where that message will be traveling to, and how it will be processed before it reaches its intended destination. A number of intermediary services may be involved in the message path, and a transport-level security technology will protect the privacy of the message contents only while it is being transmitted between these intermediaries.

In other words, SSL cannot protect a message during the time that it is being processed by an intermediary service. This does not make SSL unnecessary within a service-oriented communications framework, it only limits its role. A number of additional technologies (discussed throughout this section) are required to facilitate the message-level security required for end-to-end protection.


The WS-Security framework

This important document establishes fundamental and conceptual security standards, and also defines a set of supplementary specifications that collectively form a Web service-centric security framework. WS-Security (also known as the Web Services Security Language) can be used to bridge gaps between disparate security models, but also goes beyond traditional transport-level security to provide a standard end-to-end security model for SOAP messages.

Because service-oriented environments sometimes require that intermediaries be involved with the delivery of messages, an end-to-end security model is needed, so that the contents of SOAP messages remain protected throughout a message path. This is different from the traditional point-to-point model, for which transport-level security has generally been sufficient. In fact, you could view a message path involving intermediaries as a series of point-to-point connections

To secure a message path from end-to-end, WS-Security implements security measures through the use of SOAP header blocks that travel with the message.

Although the WS-Security framework complements a number of the specifications described earlier in this section, it is supported further by a series of supplementary standards.

WS-Security Framework
WS-Policy WS-Trust WS-Privacy
WS-SecureConversation WS-Federation WS-Authorization

The first layer below the framework is frequently referred to as the Policy Layer, as it provides a number of building blocks for the creation of trust and privacy policies. The next row, known as the Federation Layer, builds on these policies to unify disparate trust domains.


WS-Policy

Though not limited to providing security-related policies, this standard is a key part of the WS-Security framework. Existing corporate security polices can be expressed through policy assertions that can then be applied to groups of services. To learn more about WS-Policy, see the example provided in the "Robust Communication with WS-ReliableMessaging" article.


WS-Trust

This specification establishes a standard trust model used to unite existing trust models, so that the validity of exchanged security tokens can be verified. WS-Trust provides a communications process for requesting the involvement of third-party trust authorities to assist with this verification.


WS-Privacy

Organizations can use WS-Privacy to communicate their privacy policies and check to see whether requestors intend to comply to these policies. WS-Privacy works in conjunction with WS-Policy and WS-Trust.


WS-SecureConversation

Various security models can be supplemented with WS-SecureConversation, which establishes a standard mechanism for exchanging security information between Web services. It provides formal definitions for the creation and exchange of security contexts and associated session keys.


WS-Federation

There are numerous ways of integrating different trust domains (or realms) when utilizing the WS-Security, WS-Policy, and WS-Trust standards. The WS-Federation specification provides a series of standards and security models for achieving a federation — an environment where a level of trust has been established between disparate trust domains.


WS-Authorization

WS-Authorization provides a standard for managing information used for authorization and access policies. As part of this standard, the manner in which claims are represented within security tokens is established.


An Example

Due to the vast diversity of security specifications, we don’t have the luxury of delving into the concepts and language syntax of each of the standards we’ve discussed so far. To give you a glimpse into what a SOAP header block containing security information looks like, though, I’ve provided a brief example that demonstrates two fundamental parts of the WS-Security framework.

When a service requestor makes a request of a service provider, it asserts a claim regarding its security clearance. It is then up to the service provider to validate this claim. A service requestor may provide a number of claims in order to communicate different aspects of its security status. This set of claims is contained within a security token.

Security tokens can signed with a signing authority, allowing them to be further verified by the recipient of the message containing the token. Unsigned security tokens often consist of login credentials supplied by the service requestor.

The following parent Security construct establishes a WS-Security header block that consists of a token with login information.

<Security ...>
   <UsernameToken>
     <Username>
       Terl
     </Username>
     <Password>
       onedaytherewillonlybeonesecurityspec
     </Password>
   </UsernameToken>
</Security>

The UsernameToken construct contains Username and Password elements that represent the credentials claim.

SOA Design Patterns by Thomas Erl
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
Web Service Contract Design & Versioning for SOA by Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley
SOA Principles of Service Design by Thomas Erl
Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services by Thomas Erl
Service-Oriented Infrastructure:On-Premise and in the Cloud by Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso
Next Generation SOA:A Real-World Guide to Modern Service-Oriented Computing by Pethuru Cheliah, Thomas Erl, Clive Gee, Robert Laird, Berthold Maier, Hajo Normann, Leo Shuster, Bernd Trops, Clemens Utschig, Torsten Winterberg
SOA with .NET & Windows Azure: Realizing Service-Orientation with the Microsoft Platform by David Chou, John deVadoss, Thomas Erl, Nitin Gandhi, Hanu Kommalapati, Brian Loesgen, Christoph Schittko, Herbjorn Wilhelmsen, Mickey Williams
SOA Governance:
Governing Shared Services On-Premise & in the Cloud
by Stephen Bennett, Thomas Erl, Clive Gee, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable
SOA with Java by Raj Balasubramanian, David Chou, Thomas Erl, Thomas Plunkett, Satadru Roy, Philip Thomas, Andre Tost
Modern SOA Methodology: Methods for Applying Service-Orientation On-Premise & in the Cloud by Raj Balasubramanian, David Chou, Thomas Erl, Thomas Plunkett, Satadru Roy, Philip Thomas, Andre Tost
Cloud Computing: Concepts, Technology & Architecture by Thomas Erl, Zaigham Mahmood, Ricardo Puttini
Cloud Computing Design Patterns by Thomas Erl, Amin Naserpour

For more information about these books, visit: www.servicetechbooks.com


Arcitura Education Inc.
Arcitura Education Inc. is a leading global provider of progressive, vendor-neutral training and certification programs, providing industry-recognized certification programs for a range of certifications.
For more information:
www.arcitura.com
SOA Certified Professional (SOACP)
The books in this series are part of the official curriculum for the SOA Certified Professional program.
For more information:
www.soaschool.com
Cloud Certified Professional (CCP)
The books in this series are part of the official curriculum for the Cloud Certified Professional program.
For more information:
www.cloudschool.com
Big Data Science Certified Professional (BDSCP)
The books in this series are part of the official curriculum for the Big Data Science Certified Professional program.
For more information:
www.bigdatascienceschool.com/