 by Thomas Erl |
WS-* Specifications |
 |
|
|
An Overview of the WS-Security Framework |
|
| 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. |
|
| Authentication |
| The recipient of a message needs to verify that the claimed identity of the sender is valid. |
|
| 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. |
|
| Integrity |
| A message remains unaltered during transmission, up until actual delivery. |
|
| Confidentiality |
| The contents of a message cannot be viewed while in transit, except by authorized services. |
|
SOA: Principles of Service Design by Thomas Erl  An in-depth guide dedicated to service engineering with a thorough exploration of the design principles that comprise the service-orientation design paradigm (including a comparison with object-orientation). 
Service-Oriented Architecture:Concepts, Technology, and Design by Thomas Erl The first "how-to" guide to building SOA, providing coverage of WS-* specifications, .NET and J2EE platforms, and step-by-step processes for service-oriented analysis and design. 
Service-Oriented Architecture:A Field Guide to Integrating XML and Web Services by Thomas Erl The best-selling guide to service-oriented integration, providing hundreds of integration strategies and over sixty best practices. For more information about either book, visit: www.soabooks.com |
About SOA Systems
SOA Systems Inc. provides strategic SOA consulting services and offers a comprehensive SOA training program. For more information see: • www.soasystems.com • www.soatraining.com |
| 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. | |||||||||
| |||||||||
| 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. | |||||||||
| |||||||||
| 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.
| |||||||||
|
|
|
|
|
|
| Home | Copyright © 2003-2007 SOA Systems Inc. |