Section 12.3. Motivation for Using WS-Security


12.3. Motivation for Using WS-Security

Even for the last three requirements mentioned in the previous section, one can use well-established security transport-level and network-level technologies such as SSL/TLS and IPSec. SOAP supports HTTP/S. Why is WS-Security needed, yet another set of security specifications? Why are SSL/TLS and IPSec insufficient for protecting Web services transactions? Why is SOAP over HTTP/S insufficient?

WS-Security is not meant to replace any existing security technologies, and one should use them whenever they're available. Instead, WS-Security augments and federates existing security infrastructures and provides a unified model for application programmers and system administrators.

For example, when Web services are interacting within a controlled environment such as a corporation's intranet, WS-Security can propagate the original sender's identity in messages. In this model, WS-Security simply defines the interoperable XML Schema for security information and its placement in SOAP messages. This security model relies on things such as the physical security of the network, and it propagates security information to ensure the correct operation of applications that need it (for example, when a customer ID is used as a key to retrieve account information).

In a complex and hostile environment, WS-Security can provide a fuller range of protection end to end. In both the controlled and hostile environment cases, the same model and the same base mechanism are employed and are mostly transparent to applications.

In addition, existing security technologies can't solve two specific problems:

  • Web services introduces intermediaries, which might need to inspect or modify at least some parts of passing messages. These intermediaries are not always completely trusted and should not have access to sensitive data. Thus, end-to-end security for the entire message path is required. In this example, some information might need to flow through Fabrikam456 to the travel suppliers, but Fabrikam456 should not see it.

  • Web services integrates multiple systems with different security domains and technology, and thus the need for a mechanism to translate or exchange security information from one domain to another. Web services security must be extremely flexible, accommodating many different security models. In this example, an end user might authenticate itself to CompanyABC's security infrastructure. This authentication information must somehow propagate to Fabrikam456 and the travel suppliers, and it must be converted to a format that is meaningful and trustworthy for these environments.

SSL, IPSec, and HTTP-S do not meet these requirements. The can secure point-to-point connections such as those between the end user and CompanyABC's systems, or between CompanyABC's system and Fabrikam456. The integrity and confidentially aspects of these technologies have no end-to-end security or persistency. Although these technologies might provide in-transit integrity and confidentiality, these attributes are lost after the message is delivered.



    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[.  .. ] More
    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net