The Background

The standard framework for including XML-formatted security
data into SOAP messages is WS-Security

While remembering the complete WS-Security stack and its related technologies, it is very important to know the basics surrounded by it. Here are a few of those tips.

  • The same cryptography techniques (Confidentiality, Integrity, Non-repudiation and Authentication) are applied in the web services security stack as well.
  • It basically provides a XML based Abstraction Layer for the above established cryptography techniques.
  • The Transport Level Security is completely independent from the Message Level Security. For example, in order to have the Message Level Security, having HTTPS channel is optional.
  • If your requirement is to secure a message from Point A to Point B, using the Transport Level Security (That means HTTPS channel) is enough. However, if your requirement is the end-to-end security, you need to consider having Message Level Security. Then you are required to apply WS-Security.

How does WS-Security handles Authenticity, Integrity, Non-Repudiation and Confidentiality?

Security Tokens are used for Authenticity
XML Signature is used for Integrity and Non-Repudiation
XML Encryption is used for Confidentiality

WS-Security provides a mechanism that allows you to digitally sign (using XML Signature) all or part of a SOAP message. It provides a mechanism that allows you to encrypt (using XML Encryption) all or part of a SOAP message.

WS-Security supports various types of security tokens:

1. Simple Tokens (UserName/Password clear text, UserName/Password Digest)

2. Binary Tokens (x.509 Certificates, Kerberos Tokens)

3. XML Tokens (SAML, XrML, XCBF)

4. Token References (WS-SecureConversations)

Web Services Security Standards

A detailed Web Services Security Standards can be visualized as follows:

According to above diagram, WS* specifications such as WS-Trust, WS-Federation are linked to SAML specification; WS-SecureConversation is linked to XKMS; WS-SecurityPolicy and WS-authorization are linked to XACML specification.

In a distributed environment, different systems may belong to different security domains and policies. These systems may pose different PKI as well. Although SOAP makes sure the interoperability between distributed systems, dealing with different security domains remains a critical issue. This where the WS-Security specifications and the related specifications come into rescue.

XKMS provides a unified Key Management System, when there are several PKI’s in the considered distributed system.

WS-Trust adds a standard interface for a STS (Security Token Service) Provider to issue and renew security token, which can be attached to SOAP messages with WS-Security specfication.

WS-Federation translates security tokens across different domains.

SAML provides a loosely coupled identity management with the help of WS-Trust and WS-Fedeartion specifications. By doing this SAML provides Single Sign On (SSO) and the transfer of identity credentials across different trust domains. SAML utilizes XACML to add the authorization to the authenticated subject.

In my next blog post, I will go through the popular Apache Rampart WS-Security implementation in detail.

VN:F [1.9.22_1171]
Rating: 10.0/10 (2 votes cast)
VN:F [1.9.22_1171]
Rating: +5 (from 5 votes)
WS-Security - An Introduction, 10.0 out of 10 based on 2 ratings