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
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
- Windows Server 2003
- Microsoft Internet Information Services (IIS) 5.0, 5.1, or 6.0
- Microsoft .NET Framework version 1.1 or later
WSE2.0 can be downloaded at the following location:
http://www.microsoft.com/downloads/details.aspx?FamilyId=FC5F06C5-821F-41D3-A4FE-6C7B56423841&displaylang=en
Step1: Install the WSE2.0 Service Pack.
Step2: Open a project (applies to both windows and web applications) and right click the solution file. Click on the WSE2.0 settings window will be displayed as shown below:
Figure 1. Setting up WSE 2.0.
Step3: On Clicking on the WSE Settings2.0 window a popup properties windows as shown below will be displayed. Check the on "Enable the project for Web Services Enhancements" check box. See Figure 2.
Figure 2.
Step4: Steps 1 through step3 should be repeated for the project where the web service is hosted.
Step5: Now let's write a simple piece of code which accesses the web service method on which the WSE2.0 settings have been implemented.
Assuming we have a Web Service named Weatherservice already exists we write the following lines of code to access a method called GetTemperature ( ) in the project accessing the Weather web service.
Weatherservice wservice = new Weatherservice(); // Get the SoapContext object for the messageSoapContext context = wservice.RequestSoapContext;// Instantiate a new UsernameToken object.UsernameToken token = new UsernameToken (name,
Password, PasswordOption.SendNone);// Add the token to the SoapContext.context.Security.Tokens.Add(token);// Generate a signature using the username token, // and add the signature to the SoapContext.context.Security.Elements.Add(new Signature(token));try{// Call the Web method.String temperature = service.GetTemperature();
}catch(Exception ex)
{// Error handling}
We have successfully called a web service method which implements WSE 2.0.
Conclusion
WS-Security is one of the best ways of securing SOAP messages. It can be easily implemented there by reducing a lot of coding effort. It provides us the flexibility of using different entities as security tokens (Username Token, X.509 certificates etc).It secures the applications by blocking all the unauthenticated messages and messages having a invalid digital signature.
Reference
http://www.microsoft.com/downloads/details.aspx?FamilyId=FC5F06C5-821F-41D3-A4FE-6C7B56423841&displaylang=en
Step1: Install the WSE2.0 Service Pack.
Step2: Open a project (applies to both windows and web applications) and right click the solution file. Click on the WSE2.0 settings window will be displayed as shown below:
Figure 1. Setting up WSE 2.0.
Step3: On Clicking on the WSE Settings2.0 window a popup properties windows as shown below will be displayed. Check the on "Enable the project for Web Services Enhancements" check box. See Figure 2.
Figure 2.
Step4: Steps 1 through step3 should be repeated for the project where the web service is hosted.
Step5: Now let's write a simple piece of code which accesses the web service method on which the WSE2.0 settings have been implemented.
Assuming we have a Web Service named Weatherservice already exists we write the following lines of code to access a method called GetTemperature ( ) in the project accessing the Weather web service.
Weatherservice wservice = new Weatherservice(); // Get the SoapContext object for the messageSoapContext context = wservice.RequestSoapContext;// Instantiate a new UsernameToken object.UsernameToken token = new UsernameToken (name,
Password, PasswordOption.SendNone);// Add the token to the SoapContext.context.Security.Tokens.Add(token);// Generate a signature using the username token, // and add the signature to the SoapContext.context.Security.Elements.Add(new Signature(token));try{// Call the Web method.String temperature = service.GetTemperature();
}catch(Exception ex)
{// Error handling}
We have successfully called a web service method which implements WSE 2.0.
Conclusion
WS-Security is one of the best ways of securing SOAP messages. It can be easily implemented there by reducing a lot of coding effort. It provides us the flexibility of using different entities as security tokens (Username Token, X.509 certificates etc).It secures the applications by blocking all the unauthenticated messages and messages having a invalid digital signature.
Reference