Ashutosh's Blog

Analysis of XWSS and WSIT from Ohloh
Came across this inetresting website Ohloh - a resource for open source intelligence for open source projects. Its a website where you can submit the details of your open source projects (URL, cvs repositories etc) and it creates reports for your project - things like active developers, programming languages used, lines of code; commit history of developers, licences used in source files etc. I must say it looks interesting.

I created report for XWSS and WSIT - two of the projects I work on. Check the reports out and I am sure you will find some interesting things. Some interesting things I observed:

For WSIT:
1.  Over the past twelve months, 35 developers contributed new code to WSIT (Project Tango).  This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh.
2. Codebase - 94,819 LOC
3. Estimated effort - 23 Person Years
4. Languages: Java - 69%, XML - 23%, HTML - 8%

For XWSS :
1. Over the entire history of the project, 10 contributors have submitted code. 8 have done so in the last year.
2. Codebase - 117, 656 LOC ( wow xwss is ahead of wsit ;-) )
3. Estimated effort: 29 Person years

And you as a developer can claim your work in these open source projects. Here are my stats from xwss and wsit:


The results ofcourse are only from the point these two projects became open source.

Slides for BOF-4108 at Javaone 2007
Jiandong, me and Shyam presented a BOF - Interoperable Web Services Security between Java and .NET with WSIT: Ease of Development and Performance. The slides we used for the BOF are available here. If you have any questions or want some further information, please mail to users@wsit.dev.java.net or users@xwss.dev.java.net.

Disabling InclusivePrefixList in XWSS

Venu pointed out in his blog entry how one can disable generation of InclusivePrefixList in WSIT through proprietary policy assertions in WSDL. But what if you are using standalone JAXWS + XWSS with security configuration files supported by XWSS? This is exactly what a forum user recently asked at http://forums.java.net/jive/thread.jspa?messageID=209715. We now support this in XWSS 3.0 for both CanonicalizationMethod of Signature as well Transform for individual References.

Here is a sample configuration file to achieve this:

<xwss:JAXRPCSecurity xmlns:xwss="http://java.sun.com/xml/ns/xwss/config">

    <xwss:Service>
        <xwss:SecurityConfiguration dumpMessages="true">
            <xwss:Sign>
                <xwss:CanonicalizationMethod disableInclusivePrefix="true" />
                <xwss:SignatureTarget type="xpath" value="//SOAP-ENV:Body">
                    <xwss:Transform algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" disableInclusivePrefix="true"/>
                </xwss:SignatureTarget>                
            </xwss:Sign>
            <xwss:RequireSignature/>
        </xwss:SecurityConfiguration>
    </xwss:Service>

    <xwss:SecurityEnvironmentHandler>
        simple.server.SecurityEnvironmentHandler
    </xwss:SecurityEnvironmentHandler>
</xwss:JAXRPCSecurity>

Note the disableInclusivePrefix attribute for CanonicalizationMethod and Transform. This is introduced as an optional attribute and the default value for this will be false. So if you are configuring security through these configuration files and are facing interoperability issues due to some implementation not supporting InclusivePrefixList, you can set this attribute to true and try!

Technorati:Tango WSIT Glassfish Web Services XWSS Signatures WS Security

Configuring Timestamp verification in WSIT through policy assertions

Glassfish V2 beta released yesterday (12^th March 2007). It includes Microsoft Interoperability using WSIT. WSIT is being developed within the Glassfish community and will be delivered through Glassfish v2. You can learn more about WSIT and get the latest builds from the WSIT home page. Of course you do not need to download and install WSIT if you are using Glassfish beta or latest versions of Glassfish v2. Latest WSIT builds get integrated into Glassfish v2 on a periodic basic. For a tutorial on WSIT, check out tutorial.

Here I will describe some of the custom properties a user might want to set for Timestamps in the policy if he has a security enabled web service. These are custom WSIT specific policy assertions and provide additional control to the user over how to configure a service.

WS-SecurityPolicy specifies following construct to include a timestamp in SOAP Security header:

    <wsp:Policy>
        <wsp:ExactlyOne>
            <wsp:All>
               
                <sp:AsymmetricBinding>
                    <wsp:Policy>
                        .
                        .
                        .
                        <sp:IncludeTimestamp/>
                        .
                        .
                    </wsp:Policy>
                </sp:AsymmetricBinding>
                .
                .
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>

 

This makes the SOAP message include a Timestamp element in Security header with creation time and expiry time. Here is a sample message with timestamp:

<S:Envelope xmlns:S="..." xmlns:wsse="..." xmlns:wsu="...">
   <S:Header>
      <wsse:Security S:mustUnderstand="true">
         <wsu:Timestamp wsu:Id="3">
            <wsu:Created>2007-03-13T06:14:45Z</wsu:Created>
            <wsu:Expires>2007-03-13T06:19:45Z</wsu:Expires>
         </wsu:Timestamp>
         .
         .
      </wsse:Security>
   </S:Header>
   .
   .
</S:Envelope>

 

Along with creation time and expiry time, there are two other properties based on which a service in WSIT can decide to accept or reject messages based on timestamp. They are:

MaxClockSkew: This sets the maximum difference allowed between the system clocks of the sender and recipient.

Here is what WSS 1.1 spec says about clock skew: The wsu:Expires child in a Timestamp is relative to the requestor's clock. In order to evaluate the expiration time, recipients need to recognize that the requestor's clock may not be synchronized to the recipient's clock,. The recipient MUST therefore make an assessment of the level of trust to be placed in the requestor's clock, since the recipient is called upon to evaluate whether the expiration time is in the past relative to the requestor's, not the recipient. The recipient may make a judgment of the requestor's likely current clock time by means not described in the WSS specification,for example an out-of-band clock synchronization protocol. The recipient may also use the creation time and the delays introduced by intermediate SOAP roles to estimate the degree of CLOCK SKEW.

TimestampFreshnessLimit: Sets the maximum duration of time after which the timestamp becomes stale. It is RECOMMENDED that Web Service producers provide a timestamp "freshness" limitation, and that any stale timestamps be rejected. As a guideline a value of 5 minutes can be used as a minimum to detect and reject replays.

By default the value of both these properties is set to 5 minutes in WSIT. This should be good enough for most use cases. But if someone wants to specify custom values for these properties, WSIT provides proprietary policy assertions for them. This is how it could be specified in the policy:

    <wsp:Policy>
        <wsp:ExactlyOne>
            <wsp:All>
               <!-- Proprietary WSIT assertion -->
               <sc:ValidatorConfiguration xmlns:sc="http://schemas.sun.com/2006/03/wss/server" 
xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy" wspp:visibility="private" sc:maxClockSkew="0" 
sc:timestampFreshnessLimit="300000">
                <sp:AsymmetricBinding>
                    <wsp:Policy>
                        .
                        .
                        .
                        <sp:IncludeTimestamp/>
                        .
                        .
                    </wsp:Policy>
                </sp:AsymmetricBinding>
                .
                .
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>

 

where the values of sc:maxClockSkew and sc:timestampFresshnessLimit are in milliseconds. Setting MaxClockSkew to 0 might be helpful if we are sure that client and service are on same system, or if the the systems are synchronized in time. TimestampFeshnessLimit should be greater than zero as a value of zero means timestamp becomes stale immediately. The default value of 5 minutes should be good in most cases, but can be kept less to avoid replay attacks in this duration.

The same properties can be specified on client side also in the wsit-client.xml file to set maxClockSkew and timestampFreshnessLimit to required values – the only change being the namespace of properties change to http://schemas.sun.com/2006/03/wss/client. The default remains 5 minutes for both of them.

Technorati:Tango WSIT Glassfish Web Services

Security in WSIT - Some new features

Its been quite some time since milestone 2 of Web Services Interoperability Technologies (WSIT) was released. We have added a number of features and bug fixes to Security module of WSIT i.e. xwss since then. Here is a list of some of the important features/fixes you can expect from the latest promoted build or the upcoming milestone 3 release:

1. Security path is now much faster than milestone 2. We no longer convert soap messages to DOM for signing/encryption. Security operations are now performed in a streaming fashion. In other words, security operations are performed when the message is being written to transport wire. This results in huge performance gains as message is no longer converted to DOM objects. Our initial tests suggest almost a gain of 30-40% over previous implementation.

2. Support for EncryptedHeaders: WSS1.1 introduced an additional element <wsse11:EncryptedHeader> for containing encrypted SOAP header blocks. We now support this for WSS1.1 messages.
   What this means for a SOAP Message?
   If the EncryptedParts assertion for a SOAP message contains encryption of a SOAP header e.g. an addressing header, the header is first encrypted (resulting in an EncryptedData element) and then the result is wrapped with a wsse11:EncryptedHeader element.
   What are the other changes?
   If the referencing security header block contains mustUnderstand, role/actor or relay attributes, those attributes and the associated values must be copied to this wsse11:EncryptedHeader element. The ReferenceList in the referencing Security Header should now refer to this wsse11:EncryptedHeader element and not to the contained EncryptedData element.
   How does this help?
   A SOAP node can now decide if it is required to process an encrypted SOAP header. If the mustUnderstand attribute is set to true, a SOAP node/processor now must be aware of this encrypted header and know how to decrypt and convert into original header block. It should raise a fault if it cannot decrypt the block or cannot process (or understand) the decrypted block. It was not possible with just an EncryptedData as a SOAP header.

3. Support for LaxTsLast Layout: LaxTsLast (LaxTimestampLast) layout feature was not functional in WSIT till milestone 2 (Refer security status notes of M2). If a timestamp was inserted, it was always on top; this is now a supported feature. By default, we always insert Timestamp at the top of Security header in Lax and Strict modes; in LaxTsFirst, it is ofcourse supposed to be at the top.
   Is timestamp as last element in security header useful?
   If wsu:Timestamp is the first element in security header, we can process it first, and safely fail if the timestamp appears stale; thus avoiding much more time consuming signature and encryption operations. On the other hand some might say that we made a decision on freshness of timestamp without actually verifying signature – this is where LaxTsLast comes into picture; so that we can perform signature verification on timestamp before checking its freshness. Actually, it does not matter as had the timestamp been a tampered one, we would eventually reject it during signature verification. So, timestamp at top should be the popular choice as it provides the option of rejecting stale messages early in the processing. Note: WSIT always signs a wsu:Timestamp if it is included in the Security header.

4. Better Policy verification of incoming messages: Policy verification for security till Milestone 2 of WSIT was very minimal (Refer security status notes of M2) and did not work when the payload of soap message was encrypted. We now have a much better support to reject messages which do not confer to the policy of the service wsdl – e.g. some targets not being signed/encrypted, correct token inclusion policy etc. One thing we still do not check is mismatch in AlgorithmSuite values between the service policy and the policy used by the client to secure the message.

5. Apart from these features, we have had numerous bug fixes and feature additions. Give the latest WSIT a try, and put across your feedback to users@wsit.dev.java.net.

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

XWSS 2.0 on java.net
XWSS 2.0 FCS is now on www.java.net. Check it out at xwss. Do join the project if you are interested in Webservices Security and post any bugs/issues that you come across. XWSS 2.0 EA is also bundled along with JWSDP 2.0.

What's New in This Release

The following features are new to the  2.0 FCS release of XWS-Security:

• Support for Securing JAXWS 2.0  applications. Serveral samples demonstrating how to secure JAXWS 2.0  applications are located in <jwsdp_install_dir>/xws-security/samples/jaxws2.0.
• Support for Securing SOAP 1.2 Applications.
  
• Partial support for WS-I Basic Security Profile (BSP) 1.0. The Current Limitations section includes a list of unsupported BSP assertions.
• Improved Overall Performance from XWS-Security 2.0 and an option to specify a boolean shema attribute named  optimize  on <xwss:JAXRPCSecurity> configuration element that allows certain common security usecases to be optimized under JAXWS 2.0.
• Refined, Simplified and Stable Programmatic APIs  (over what was present in previous releases). These APIs can be used by standalone SAAJ based applications for securing  SOAP Message exchanges. Refer javadocs and sample located at  <jwsdp-install-dir>/xws-security/samples/saajsecurity.
• Refined Dynamic Policy support  over what was present in previous releases. Refer javadocs and sample located at <jwsdp-install-dir>/xws-security/samples/dynamicpolicy.
• API  to obtain runtime properties set on a JAXRPC Stub or a JAXWS BindingProvider  inside a Callback. The runtime properties can be used by the callbackhandler to make dynamic decisions about the returned keys and security policies.
• The special QNAME constant  SOAP-BODY can now be used in XWS-Security configuration files to indicate a SOAP 1.1 or a SOAP 1.2 Body. For example one can write the following configuration to sign the SOAP Body irrespective of the SOAP Protocol.

        <xwss:Sign>
        <xwss:X509Token certificateAlias="xws-security-client"/>
        <xwss:SignatureTarget type="qname" value="SOAP-BODY"/>
    </xwss:Sign>



What This Release Includes

This release includes the following XML and Web Services Security (XWS-Security) features:

• Support for securing JAXWS, JAX-RPC and SAAJ applications.
  
• A  security framework within which a JAXWS or JAX-RPC application developer will be able to secure applications by signing/verifying and/or encrypting/decrypting parts of a SOAP message and/or message Attachments. The message sender can make claims about the security properties by associating security tokens with the message. An example of a security claim is the identity of the sender, identified using user name and password.
• Web Services Security (WSS) interoperability scenarios. Developers will be able to send and receive messages compliant with the WSS Soap Message Security specification. Developers can use the framework to implement applications which have security requirements similar to those defined in the WSS interoperability scenarios. More information on the scenarios can be found at Draft Spec for Interop1 (draft 5), Final Spec for Interop2 (draft 6), or from the Oasis home page.

  This release includes samples that demonstrate the following WSS interoperability scenarios:

  • WSS Interop Scenarios 1, 2, 3, 4, 5, and 6 are demonstrated in the simple sample.
  • SwA Interop Scenarions 1, 2, 3, and 4 are demonstrated in the swainterop sample.
  • SAML Interop Scenarios 1, 3, and 4 are demonstrated in the samlinterop sample.
• XWS-Security APIs for securing applications that make use of SAAJ APIs only. Developers who are using plain SAAJ (and not JAX-RPC) can make use of these APIs in conjunction with XWS-Security to secure their SOAP messages.  Refer javadocs and the sample <jwsdp-install-dir>/xws-security/samples/saajsecurity for more details.

• Advanced Encryption Standard AES-256 is supported as a data encryption algorithm.