Ashutosh's Blog

Tech Tip on Securing Attachments in Metro 1.3

My tech tip on Security Attachments in Metro 1.3 using Netbeans 6.5 Beta is now available here.

Hash Password Support and Token Assertion Parameters in Metro 1.2

Metro 1.2 released just before Javaone. The Security component has two major feature support from the Security Policy 1.2 specification:

• Digest(Hash) Password Support

• Availability of Security Token Assertion parameters like Issuer, IssuerName and Claims for verification by users.

Both these features are available for the Security Policy 1.2 namespace.

Apart from this there are many bug fixes. Please refer the status notes for Security and Security Policy.

Digest Password Support

The WSS 1.1 Username Token Profile allows digest passwords to be sent in a wsse:UsernameToken of a SOAP message. Two more optional elements are included in the wsse:UsernameToken in this case: wsse:Nonce and wsse:Created. A nonce is a random value that the sender creates to include in each UsernameToken that it sends. A creation time is added to combine nonces to a “freshness” time period. The Password Digest in this case is calculated as:

Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )

This is how a UsernameToken with Digest Password looks like:

<wsse:UsernameToken wsu:Id="uuid_faf0159a-6b13-4139-a6da-cb7b4100c10c">
   <wsse:Username>Alice</wsse:Username>
   <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">6S3P2EWNP3lQf+9VC3emNoT57oQ=</wsse:Password>
   <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">YF6j8V/CAqi+1nRsGLRbuZhi</wsse:Nonce>
   <wsu:Created>2008-04-28T10:02:11Z</wsu:Created>
</wsse:UsernameToken>

The Security Policy assertion for a UsernameToken with digest password looks like:

<sp:SignedSupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
   <wsp:Policy>
      <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
         <wsp:Policy>
            <sp:WssUsernameToken10 />
            <sp:HashPassword />
         </wsp:Policy>
      </sp:UsernameToken>
   </wsp:Policy>
</sp:SignedSupportingTokens>

The testcase s17 available at https://wsit.dev.java.net/source/browse/*checkout*/wsit/wsit/test/e2e/testcases/xwss/s17 provides a sample for Digest Password scenaro and the complete WSDL can be accessed at wsdl. The service needs to provide an implementation of abstract class PasswordValidationCallback.WsitDigestPasswordValidator. The testcase includes a sample implementation. The implementation class name is specified in the ValidatorConfirguration of the WSDL:

<sc:ValidatorConfiguration xmlns:sc="http://schemas.sun.com/2006/03/wss/server">
   <sc:Validator name="usernameValidator" classname="xwss.s17.server.SampleWsitDigestPasswordValidator" />
</sc:ValidatorConfiguration>

Tooling support for Hash Password will come with the 1.3 release of Metro.

Availability of Security Token Assertion parameters like Issuer, IssuerName and Claims to end users

SecurityPolicy 1.2 spec allows a token assertion to carry optional sp:Issuer or sp:IssuerName elements and wst:Claims element. In the earlier version, these elements were only allowed for an IssuedToken assertion. We make this information available in com.sun.xml.wss.TokenPolicyMetaData class, and it can be used ,for example, in a CallbackHandler. Here is a code snippet:

SAMLCallback cb = ...
Map props = cb.getRuntimeProperties();
com.sun.xml.wss.TokenPolicyMetaData metaData = new
com.sun.xml.wss.TokenPolicyMetaData(props);

String issuer = metaData.getIssuer();
org.w3c.dom.Element claims = metaData.getClaims();

The Issuer or IssuerName information is available as a String, representing the URI. The Claims information is available as a DOM Element.

Metro at Sun Tech Days Hyderabad

Myself and Shyam presented Metro - Everyday Web Services at Sun Tech Days, Hyderabad. The slides we used for the session are available here. The session was very well attended with 1000+ people turning up, and we had lots of questions in the QnA session and after the session as well. If you were at the session and still have some questions on Metro stack, please post them at users@metro.dev.java.net alias.

Here are some of the pics we took at the event:
 

Kerberos token based WS Security Scenarios on Tomcat

My previous blog Running Kerberos Token Profile scenario with Metro showed how to run kerberos token based WS-Security scenarios on Glassfish. Here I show the small changes you need to do to run it on Tomcat. The steps essentially boil down to specifying the location of JAAS login config file where login modules for Kerberos are stored. Glassfish picks the login modules from $GLASSFISH_HOME/domains/domain1/config/login.conf, in Tomcat we need to specify the file explicitly using java.security.auth.login.config system property.

Here are the complete steps:

1. Create a file jaas.conf , and place it in $CATALINA_HOME/conf. Here's what jaas.conf looks like:

           KerberosClient { 
               com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true; 
           };
   
           KerberosServer { 
               com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/etc/krb5.keytab" doNotPrompt=true storeKey=true principal="websvc/service@INDIA.SUN.COM"; 
           };
           

2. Add following line to the catalina.sh script (or specify the mentioned JAVA_OPTS property):

           JAVA_OPTS="$JAVA_OPTS "-Djava.security.auth.login.config=$CATALINA_HOME/conf/jaas.conf
           

3. Specify the following system property in your client code:

       -Djava.security.policy=${tomcat.home}/conf/catalina.policy
       -Djava.security.auth.login.config=${tomcat.home}/conf/jaas.conf
       

Running Kerberos Token Profile scenario with Metro

As promised in my previous blog, I have tried to put here steps to run a Kerberos Token Profile based WS Security scenario using Metro. Please note that the Kerberos support in Metro is still experimental, and we do not provide a Netbeans support for it yet. Consequently, one has to modify the xml configuration files produced through Netbeans manually to test Kerberos. Netbeans support for Kerberos will come with one of the future release of Metro.

Setting up Kerberos

1. Install and setup Kerberos appropriate to your environment. The following blogs give good account on how to setup Kerberos for Solaris 10 and Ubuntu Linux:

   • For Solaris 10: http://blogs.sun.com/tdh/entry/installing_a_kerberos_kdc_and

   • For Ubuntu Linux: http://www.alittletooquiet.net/text/kerberos-on-ubuntu/

Make sure DNS lookups (or whatever name service in /etc/resolv.conf) to the kdc are working correctly.

                     # nslookup [hostname]
                     # nslookup [ip address]

2. Add user accounts for kerberos client and service to use

• Create a user principal for your kerberos account. It is used to administer the kerberos account.

                     # kadmin.local -q "addprinc admin/admin"
                     [type password]

• Add user accounts for kerberos client and service to use

                      #kadmin.local -p admin/admin
                       kadmin.local: addprinc -randkey -e "aes128-cts-hmac-sha1-96:normal" [service_principal]
                                     (Ex of service_principal: websvc/service)
                       kadmin.local: addprinc -e "aes128-cts-hmac-sha1-96:normal" [client_principal]
                       [type password]
                                    (Ex of client_principal: testClient)
                       kadmin.local: ktadd -e "aes128-cts-hmac-sha1-96:normal" [service_principal]
                       kadmin.local: quit

• Login to your kerberos account just created.

                      #kinit [client_principal]
                       [type password] 

Setting up Glassfish and Metro to run Kerberos Scenario

        1. Specify the login modules to be used for Kerberos in <GLASSFISH_HOME>/domains/domain1/config/login.conf. Paste the following at the bottom of this file:

                KerberosClient { 
                     com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true; 
                }; 

                KerberosServer { 
                     com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/etc/krb5.keytab" doNotPrompt=true storeKey=true principal="websvc/service@INDIA.SUN.LOCAL"; 
                }; 

You can give any names to this login modules (instead of KerberosClient and KerberosServer). You will have to refer to these names from the <sc:KerberosConfig> assertion in the wsdl and wsit-client.xml files.

Also edit the principal in KerberosServer to the service_principal you created.

        2. Create a Secure JAX-WS application using Netbeans. Refer 'Using WSIT Security' chapter from WSIT tutorial. Use any Security mechanism e.g. Mutual Certificates Security. Open the <wsit-service-name>.xml file created and replace the Binding level policy with the following policy:

Note the element <sc:KerberosConfig xmlns:sc="http://schemas.sun.com/2006/03/wss/server"/> which points to the LoginModule to be used for the service.

        <wsp:Policy wsu:Id="IFinancialService_policy">
         <wsp:ExactlyOne>
            <wsp:All>
                <wsaws:UsingAddressing xmlns:wsaws="http://www.w3.org/2006/05/addressing/wsdl"/>
                <sp:SymmetricBinding>
                    <wsp:Policy>
                        <sp:ProtectionToken>
                            <wsp:Policy>
                                <sp:KerberosToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once">
                                    <wsp:Policy>
                                        <!--<sp:RequireDerivedKeys />-->
                                        <sp:WssGssKerberosV5ApReqToken11/>
                                    </wsp:Policy>
                                </sp:KerberosToken>
                            </wsp:Policy>
                        </sp:ProtectionToken>
                        <sp:Layout>
                            <wsp:Policy>
                                <sp:Strict/>
                            </wsp:Policy>
                        </sp:Layout>
                        <sp:IncludeTimestamp/>
                        <sp:OnlySignEntireHeadersAndBody/>
                        <sp:AlgorithmSuite>
                            <wsp:Policy>
                                <sp:Basic128/>
                            </wsp:Policy>
                        </sp:AlgorithmSuite>
                    </wsp:Policy>
                </sp:SymmetricBinding>
                <sp:Wss11>
                    <wsp:Policy>
                        <sp:MustSupportRefKeyIdentifier/>
                        <sp:MustSupportRefIssuerSerial/>
                        <sp:MustSupportRefThumbprint/>
                        <sp:MustSupportRefEncryptedKey/>
                    </wsp:Policy>
                </sp:Wss11>
                <sc:KerberosConfig xmlns:sc="http://schemas.sun.com/2006/03/wss/server" loginModule="KerberosServer"/>
            </wsp:All>
        </wsp:ExactlyOne>
        </wsp:Policy>

Deploy this service.

        3. Create a client to access this service using Netbeans. Refer to the WSIT tutorial as mentioned in point 2. Edit wsit-client.xml file created (or the file included in wsit-client.xml) and replace sc:KeyStore and sc:TrustStore elements with:

<sc:KerberosConfig wspp:visibility="private" loginModule="KerberosClient" servicePrincipal="websvc/service@INDIA.SUN.LOCAL"/>

Modify the loginModule to the one you created for client in login.conf file for the client and the servicePrincipal to the name of the service principal for which ticket needs to be obtained. If your client is a Java SE client, you need to set the following system properties while running your client code:

-Djava.security.policy=${glassfish.home}/domains/domain1/config/server.policy

-Djava.security.auth.login.config=${glassfish.home}/domains/domain1/config/login.conf

If it is WebApp deployed on glassfish, nothing else needs to be done. Deploy and run the client.

Updated on 9 Jan 2008

Kerberos support in Metro security now supports credential delegation from client to service, such that the server can initiate other security contexts on behalf of the client. This feature is useful for single sign-on in a multi-tier environment.

The way for client to ask for credentials delegation is to set the attribute credentialDelegation to true on KerberosConfig element in wsit-client.xml. For example:
<sc:KerberosConfig wspp:visibility="private" loginModule="KerberosClient" servicePrincipal="websvc/service@INDIA.SUN.LOCAL" credentialDelegation="true" />

At the service, we can obtain the delegated credentials from the Subject of the authenticated user. The PrivateCredential set of the will have the delegated client credentials (as GSSCredential). We can pass this GSSCredential to GSSManager.createContext() pretending to be the client.

Also, the PublicCredential set of the authenticated Subject will always have KerberosPrincipal corresponding to the client.

Web Services Interoprability Plugfest and Kerberos Token support in Metro

Sun participated in the latest Web Services Interoperability Plugfest hosted by Microsoft at their Redmond campus from November 6^th to 8^th. Harold, Jiandong and myself represented Sun at this event. Harold has a put forward a detailed entry with the details on the scenarios we tested and the results. Jiandong explains the WS-SX tests and the versions of specs they cover in his blog.

My focus at this event was to test for the first time our implementation of Kerberos Token Profile 1.1 for interoperability with .NET 3.x. The most difficult part for Kerberos interoperability turned out to be setting up the Kerberos infrastructure for trust. Once we were through this part, all the tests passed without any difficulty. The tests consisted of the following scenarios:

Basic Kerberos token tests

Kerberos Token with Derived Keys

SecureConversation with Kerberos token in Bootstrap policy

SecureConversation with Kerberos token and Derived Keys in Bootstrap policy

All these scenarios are available at the public endpoint from Microsoft at http://mssoapinterop.org/ilab/ . Harold has details on the exact tests and results in his blog.

These tests were run using a single KDC for WSIT client and WCF service and vice versa.

The Kerberos token support will release with a future release of Metro, but if you want to give it a try, you can get one of the nightlies from here. I plan to blog about setting up kerberos infrastructure and running kerberos scenarios in coming weeks.

The next step we want to try is to use different KDCs for client and service and test cross-domain security using Kerberos. We tried it this time and ran across some setup issues with DNS configurations and cross domain trust.

Custom Security Policy Assertions in Metro

Metro 1.0 FCSed two days back (on 09/17). It is a high performance, extensible, easy to use web service stack. Metro combines JAXWS RI implementation with Project Tango. Project Tango implements numerous WS-* standards to enable the various Quality of Service(QOS) features in web services like security, reliability, transactions etc and to ensure interoperability with other implementations based on standards. We have performed extensive testing for interoperability with .NET 3.0. Metro comes bundled as part of Glassfish V2 (which also FCSed on the same date). Metro can also be run on other containers like Tomcat.

Project Tango implements WS-Policy which provides for an interoperable way to configure the QOS attributes of a web service. The security requirements of a web service are specified using WS-Policy assertions defined by WS-SecurityPolicy (a domain specific binding of WS-Policy). The version of WS-SecurityPolicy implemented in 1.0 release is 2005/07. This is the same version that .NET 3.0 implements. WS-SecurityPolicy 1.2 was recently approved as OASIS standard and the next release of Metro will also support this version.

In the past we have listed some of the custom security policy assertions in various blogs and forum posts that Project Tango allows, to achieve different features or behaviors outside of the specification. With the release of Metro 1.0, I think it is right time to list all of them at one place. We have provided most of these assertions based on requirements from various users to support features outside of specification or to configure if security should be processed by a different path. In most cases you should not need these assertions. So here we go:

DisableStreamingSecurity:

Server side policy assertion:
<sunsp:DisableStreamingSecurity xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"></sunsp:DisableStreamingSecurity>

Client side policy assertion:
<sunsp:DisableStreamingSecurity xmlns:sunsp="http://schemas.sun.com/2006/03/wss/client"></sunsp:DisableStreamingSecurity>

The default security implementation in WSIT is streaming security implementation (not based on DOM). The performance benefits we achieve with this implementation over our older DOM based implemenatation is huge. So, we no longer need DOM (or SAAJ) to support most common use case scenarios. But this implementation has some limitations – like we do not support XPATH i.e. SignedElements and EncryptedElements in SecurityPolicy. So in case you need Signed or Encrypted Elements, you can switch back to our DOM based security implementation using these assertions. Check more at this post from Venu.

DisableInclusivePrefixList :

Server side policy assertion:
<sunsp:DisableInclusivePrefixList xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"></sunsp:DisableInclusivePrefixList>
Client side policy assertion:
<sunsp:DisableInclusivePrefixList xmlns:sunsp="http://schemas.sun.com/2006/03/wss/client"></sunsp:DisableInclusivePrefixList>

Tango security by default generates InclusivePrefixList for Exclusive Canonicalization algorithm. But, not many implementations support this. So, in case you face an interoperability issue where messages containing InclusivePrefixList are rejected, you can disable generation of InclusivePrefixList in Exclusive Canonicalization. Check more at Venu's blog entry. Also, look at my previous post on how to disable this feature if you are using standalone JAXWS+XWSS with security configuration files supported by XWSS.

EncryptHeaderContent :

Server side policy assertion:
<sunsp:EncryptHeaderContent xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"></sunsp:EncryptHeaderContent>

Client side policy assertion:
<sunsp:EncryptHeaderContent xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"></sunsp:EncryptHeaderContent>

The version of SecurityPolicy we implement only allows encryption of the entire header. Content encryption of SOAP headers is not allowed. So, in case you need to encrypt just the content of the SOAP header, you can use this assertion. We provided this support as it was needed as part of the WS-I BSP 1.0 interop. More details on the event here and here. Note that if the other party you are interoperating with implements the same standards we do, you should never need this assertion. This will only be required if the other party has some implementation not based on these WS-* standards and encrypts just the content of headers.

BSP10:

Server side policy assertion:
<sunsp:BSP10 xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"></sunsp:BSP10>

Client side policy assertion:
<sunsp:BSP10 xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"></sunsp:BSP10>

As the name of the assertion suggests, you can add this assertion if you want your service (or client) to be WS-I BSP 1.0 compliant. Again this assertion was added as part of the WS-I BSP 1.0 interop event. Check more details on the sample and scenarios at this entry from Arun.

InclusiveC14NWithComments :

The Security Policy specification only allows Exclusive and Inclusive canonicalization algorithms. But we had some users of Tango who wanted the support for InclusiveC14NWithComments canonicalization algorithm as they wanted to interop with some older versions of Axis 1.x and WSS4J which used these algorithms. So, we have provided a custom assertion to use this canonicalization algorithm. Below is a sample policy which demonstrates how you can use this assertion. Note that this feature only works with non-streaming security in 1.0 release of Metro, so you will need to add the assertion to disable streaming security as well.

<wsp:Policy wsu:Id="BindingPolicy">
       <wsp:ExactlyOne>
           <wsp:All>
               <sp:AsymmetricBinding
               .
               .
                       <sp:AlgorithmSuite>
                           <wsp:Policy>
                               <sp:Basic256/>
                               <!-- ADD THIS TO ENABLE INCLUSIVE CANONICALIZATION, DEFAULT IS EXCLUSIVE -->
                               <sp:InclusiveC14N/>

                               <!-- ADD THIS TO ENABLE INCLUSIVE CANONICALIZATION WITH COMMENTS,
                                FOR ENABLING THIS PROPERTY FOR TRANSFORMS SET sunsp:forTransforms to TRUE
                                FOR ENABLING THIS PROPERTY FOR CANONICALIZATION METHOD SET sunsp:forCm to TRUE
                                DEFAULT IS FALSE FOR BOTH, SO YOU NEED TO EXPLICITLY SPECIFY THE ATTRIBUTES-->
                               <sunsp:InclusiveC14NWithComments sunsp:forTransforms="true" sunsp:forCm="true" xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"/>

                           </wsp:Policy>
                       </sp:AlgorithmSuite>
               .
               </sp:AsymmetricBinding>
.
.
            <!-- THIS SUPPORT ONLY WORKS THROUGH NON-OPTIMIZED PATH -->
             <sunsp:DisableStreamingSecurity xmlns:sunsp="http://schemas.sun.com/2006/03/wss/server"></sunsp:DisableStreamingSecurity>
.
.
           </wsp:All>
       </wsp:ExactlyOne>
   </wsp:Policy> 

ExclusiveC14NWithComments :

This assertion is similar to the previous assertion, except that it allows you to use ExclusiveC14NWithComments algorithm.

These assertion are apart from the custom assertions we allow to configure KeyStores, TrustStores, CertStores,Validators and Callbackhandlers. You can read in detail about these assertions and more about web service security features in Metro here.

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.

Tracking WSIT Blogs

Came across this blog from Dims on using Yahoo Pipes to keep tab on blogs about Axis2. I created one for WSIT. Here it is:

http://pipes.yahoo.com/pipes/WM1JGye82xGOpXguFG_cUw/

It combines feeds from Technorati, Google Blogsearch and Bloglines and then sorts them based on date. You can get the results delivered to your inbox or subscribe to the feed. Check out the Subscribe link on right side.

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.