WS-Security

This document provides an overview over all articles resulting from my search related to WS-Security.

Content

General

  • WS-Security has emerged as the de facto method of inserting security data into SOAP messages [On02]
  • work began in 2001 [On02]
  • published in April 2002 by Microsoft, VeriSign, and IBM [On02]
  • submitted in June 2002 to the OASIS standards body in order to be made into an industry standard. [On02]
  • defines placeholders in the SOAP header in order to insert security data [On02]
  • defines how to add encryption and digital signatures to SOAP messages, and then a general mechanism for inserting arbitrary security tokens [On02]
  • defines a set of SOAP header extensions for end-to-end SOAP messaging security [Sh03]
  • supports message integrity and confidentiality by allowing communicating partners to exchange signed and encrypted messages in a Web services environment [Sh03]
  • because it is based on XML digital signature and XML Encryption standards, you can digitally sign and encrypt any combination of message parts [Sh03]
  • supports multiple security models, such as username/password-based and certificate-based models [Sh03]
  • supports multiple security technologies, including Kerberos, PKI, SAML, and so on [Sh03]
  • supports multiple security tokens; for example, tokens that contain Kerberos tickets, X.509 certificates, or SAML assertions [Sh03]

What is WS-Security?

Article foundFact
Web Service Security [On02] WS-Security is "tight" enough to present the definitive means of including security data into SOAP messages, but is "loose" enough to not place limits on what that security data can be.
Secure, Reliable, Transacted Web Services [FS03]
  • WS-Security is the basic building block for secure Web services
  • Today, most distributed Web services rely on transport level support for security functions. Examples are HTTP/S and BASIC-Auth authentication. These approaches to security provide the minimum necessary for secure communication. The level of function they provide, however, is significantly less than that provided by existing middleware and distributed environments.
  • uses existing security models (Kerberos, X509, etc). The specifications concretely define how to use the existing models in an interoperable way. Multi-hop, multi-party Web service computations cannot be secure without WS-Security.

How WS-Security Standards play together

Article foundFact
Security for Parlay-X - challenges and solutions [Eckardt] Security Standards in Concert

WS-Security toolkits vs. WS Security Gateways

Article foundFact
Security for Parlay-X - challenges and solutions [Eckardt]

WS-Security toolkits:

  • Security implemented as part of the application
    • implementation (coding) needed in every single end-system
    • toolkits available for some security functionality
    • resource-intensive (CPU cycles) processing needed at Parlay-X Gateway
      • severe impact on service-handling capacity of Parlay-X Gateway
      • denial-of-service by heavy loads of requests for execution of security mechanisms (authentication, encryption, dig. signature)
    • WS-Security standardization cycles and application release cycles must be coordinated

  • Drawbacks
    • security and application code mixed
    • security integration may involve modifying source code
    • potential vendor dependencies (APIs, mgt. of security etc.)
    • security management involves multiple hosts and pieces of software
    • WS-Security processing is extremely hungry for CPU cycles!

WS-Security Gateways:

  • SOAP Security Proxy
    • provides a virtual service endpoint (hides URL of Parlay-X Gateway)
    • messages sent to the security proxy,
      • inspected there ("content inspection"),
      • content filtering, parameter filtering, SLA enforcement
      • (if approved by the content inspection) forwarded to the Parlay-X Gateway
      • rule-based selection of specific Parlay-X GW (load-balancing, SLA, security)
    • -> SOAP Firewall

  • Application-level security (3-4A) gateway
    • CPU-intensive processing offloaded to highly specialized system:
      • authentication (at the perimeter)
      • authorization
      • confidentiality (selective encryption/decryption)
      • integrity (selective XML digital signatures)
      • audit
      • centralized administration (of security policies, audit trails, OAM)

  • Advantages of SOAP Security Proxies
    • provide very comprehensive set of WS-Security standards
    • emerging security standards tightly tracked and timely implemented
    • transparent integration with heterogeneous portfolio of Parlay-X applications and other telco Web Services
      • with planned systems
      • into existing systems in production environments! (no coding!)
    • complete separation of application form security functions
    • CPU-intensive processing offloaded to proxies
    • often built to enterprise-grade requirements
      • performance, scalability
      • manageability
      • centralized control via remote policy server
      • high availability/ failover support