WS-Security is a security mechanism for web services coined by IBM, Microsoft and VeriSign. WS-Security introduces the concept of security tokens. These XML-based tokens contain claims about the sender of a SOAP message, and can include data sufficient to prove these claims. Username tokens, which will be the focus of this article, can contain a username and optionally a password or a cryptographically-derived password hash. Signed security tokens, such as X.509 or Kerberos-based tokens, are binary security tokens encoded as base-64 binary XML. They include cryptographic endorsements made by a token-issuing authority.
WSE2.0 (Web Service Enhancements) Features
This section describes the new and enhanced features included in the WSE 2.0 and its implementation in .NET.
Policy
WSE version 2.0 enables developers to use configuration files to specify requirements for receiving and sending messages. Now those requirements, known as policy assertions, can be expressed in a configuration file. When policy assertions are configured, WSE runtime checks incoming or outgoing SOAP messages to determine whether they comply with the policy assertions; when they do not, WSE runtime returns a SOAP fault. WSE has a set of predefined policy assertions, such as the requirement that the body of the SOAP message be signed with an X.509 certificate. In addition, the policy system can be extended to include custom policy assertions.
WS-Trust and Security Context Tokens
WSE's support of the WS-Trust and WS-Secure Conversation specifications provides the capability to programmatically request a security token using a SOAP message, and that token can be used for a series of SOAP messages between a SOAP message sender and a target Web service. WSE allows you to build a security token service or configure one that issues security context tokens. When configured to issue security context tokens, a SOAP message sender can use the token to sign and/or encrypt a series of SOAP messages, known as a conversation, between a SOAP message sender and the target Web service.
Kerberos Security Tokens
WSE supports the use of security tokens based on Kerberos tickets. Kerberos tickets can be used to digitally sign and encrypt SOAP messages, along with authorizing access to a Web service based on a Kerberos security token.
Role-based Security Using Security Tokens
WSE supports role-based authorization for SOAP messages by constructing a principal from a security token in the SOAP message, such as the one used to digitally sign the SOAP message.
Signing and Encrypting Security Tokens
When a security token is added to a SOAP message, it is added to the SOAP message in the form of an XML element in the WS-Security SOAP header. That XML element can now be digitally signed or encrypted. This can be very useful when the security token is a Username Token, which is based upon a user name and password especially if the password is sent in plaintext. And when you use role-based security with a Username Token, the password must be sent in plaintext. Therefore, encrypting the Username Token containing a plaintext password can make it more difficult for an intermediary to steal a user's password.
SOAP Messaging
With SOAP messaging, WSE supports a flexible and lightweight mechanism for sending and receiving SOAP messages. This mechanism allows applications to switch between the TCP and HTTP transport protocols relatively easily.
How to implement security using WSE2.0?
To implement the WS-Security specification in your Web service or consuming client application, you must be able to write security elements to and read them from your SOAP messages, and you must have access to standard cryptographic algorithms. All messages sent to a WSE-enabled application must contain at least one security token.
System Requirements
Join the conversation! Your thoughts help the community grow.