Ashutosh's Blog

Overview of security in WSIT
      Project Tango is a Sun initiative focused on delivering  interoperable Web services technologies. Web Services Interoperability Technology (WSIT) is an open-source implementation of next generation Web services technologies that deliver interoperability between Java EE and .Net to help you build, deploy, and maintain Composite Applications for your Service Oriented Architecture. It is focused on four main categories: Messaging, Metadata, Security, and Quality-of-Service (QoS). 

      Here I'll be giving a brief overview about the Webservices security and security specifications supported in WSIT. Security is an important issue for the adoption and popularity of webservices - and an important factor in deciding whether webservices and SOA will live upto the expectations created around it.

      WSIT provides support for WSS: SOAP Message Security (1.0 and 1.1), WS-Trust and WS-SecureConversation. WS-SecurityPolicy is used to document the security support offered by a webservice. 

      Security in webservices must provide atleast these three basic requirements:
- Requests to a webservice must be autheticated and authorized properly - only the intended person should be able to use the service.
- Messages 'on the wire' must be protected from eavesdroppers.
- Trust relationships between sender and recipient for exchange of certificates and tokens.

      WSS:SOAP Message Security 1.0 provides the underlying foundation for security and provides the following:
- Identifying the origin of a message securely through the use of signatures.
- Making sure no has tampered with the message - again through signatures (Integrity).
- Making sure only the intended recipient is able to see the message - through encryption (confidentiality).

      WSS 1.0 introduces a Security header in a SOAP message and introduces three key elements:
1. Tokens: SOAP messages can contain security tokens with authentication information like Username tokens, X509 Tokens, SAML tokens etc. These tokens can be part of security headers and can vouch for security claims to recipient.
2. Signature Elements: Security headers can contain Signature elemets which can sign any part of the message. The recipient can use signature to verify that sender's request has not been changed and that message came from the sender.
3. Encryption Eelements: Parts of SOAP messages can be encrypted to protect sensitive information, so that only receiver can read it.

      WSS 1.1 enhances WSS 1.0 with some addtional mechanisms to convey token information (like sending thumprint of an X509, or a SHA1  of an Encrypted key already available with both the parties). WSS 1.1 also introduces the concept of SignatureConfirmation. In certain situations it is desirable that the initiator confirms that the message received was generated in response to a message it initiated in its unaltered form - so the recipient sends back the signature values received from initiator in SignatureConfirmation elements. This helps prevent certain forms of attacks.

      WS-Trust provides a model for exchange, issuance, renewal etc of security tokens to be used in messages. A requester examines the SecurityPolicy statements associated with a webservice to find out the type and authority of tokens that the webservice requires in messages it accepts. If the requester does not already contain the tokens, it must obtain it from the Security Token Service (STS) that the webservice's SecurityPolicy mentions. An STS is a webservice that has a WSDL interface and accepts SOAP messages. An STS can issue, renew and validate security tokens through SOAP messages. This is a simple overview of what WS-Trust does - the model is pretty extensible where a response from STS can contain key information for requester and STS to derive keys, lifetime of the tokens etc. WS-Trust also defines a model for challenges. Upon receiving a message with a token, a service might send a challenge, forcing the requester to demonstrate its right to use the token. Trust also provides support for specifying key sizes and algorithms in request and response messages. For addtional details refer to the initial public draft release of WS-Trust specification here.

      WS-SecureConversation introduces the concepts of session specific keys in SOAP Message Security - similar to what SSL/TLS has. This allows for improved security of keys as using the same public keys for large amounts data time and again reduces the security of the keys. SecureConversation introduces the concepts of Security Context and Security Context Token (SCT). SecureConversation can be used along with Trust which allows STS to generate and return SCTs. For complete review refer to the revised public draft release of WS-SecureConversation here.

      For more information on Web Services Interoperability Technology (WSIT), please go to http://java.sun.com/webservices/interop. 

      For more information on the open source project on java.net, please go to the project page at wsit.dev.java.net. We encourage you to join the project, download, contribute and provide feedback.

     
Technorati: wsit