Thursday Dec 06, 2007

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:

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

                     # nslookup [hostname]
                     # nslookup [ip address]
  1. 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 { 
            required useTicketCache=true; 

                KerberosServer { 
            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=""/> which points to the LoginModule to be used for the service.

        <wsp:Policy wsu:Id="IFinancialService_policy">
                <wsaws:UsingAddressing xmlns:wsaws=""/>
                                <sp:KerberosToken sp:IncludeToken="">
                                        <!--<sp:RequireDerivedKeys />-->
                <sc:KerberosConfig xmlns:sc="" loginModule="KerberosServer"/>

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:${glassfish.home}/domains/domain1/config/server.policy${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.

Friday Nov 16, 2007

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 6th to 8th. 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 . 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.

Wednesday Sep 19, 2007

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:


Server side policy assertion:
<sunsp:DisableStreamingSecurity xmlns:sunsp=""></sunsp:DisableStreamingSecurity>

Client side policy assertion:
<sunsp:DisableStreamingSecurity xmlns:sunsp=""></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=""></sunsp:DisableInclusivePrefixList>
Client side policy assertion:
<sunsp:DisableInclusivePrefixList xmlns:sunsp=""></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=""></sunsp:EncryptHeaderContent>

Client side policy assertion:
<sunsp:EncryptHeaderContent xmlns:sunsp=""></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.


Server side policy assertion:
<sunsp:BSP10 xmlns:sunsp=""></sunsp:BSP10>

Client side policy assertion:
<sunsp:BSP10 xmlns:sunsp=""></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">

                                FOR ENABLING THIS PROPERTY FOR TRANSFORMS SET sunsp:forTransforms to TRUE
                               <sunsp:InclusiveC14NWithComments sunsp:forTransforms="true" sunsp:forCm="true" xmlns:sunsp=""/>

             <sunsp:DisableStreamingSecurity xmlns:sunsp=""></sunsp:DisableStreamingSecurity>

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.

Wednesday Jul 18, 2007

Analysis of XWSS and WSIT from Ohloh

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:

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:
ohloh profile for Ashutosh Shahi

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

Friday May 11, 2007

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 or

Tuesday Mar 27, 2007

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 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="">

        <xwss:SecurityConfiguration dumpMessages="true">
                <xwss:CanonicalizationMethod disableInclusivePrefix="true" />
                <xwss:SignatureTarget type="xpath" value="//SOAP-ENV:Body">
                    <xwss:Transform algorithm="" disableInclusivePrefix="true"/>


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

Tuesday Mar 13, 2007

Configuring Timestamp verification in WSIT through policy assertions

Glassfish V2 beta released yesterday (12th 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:



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="...">
      <wsse:Security S:mustUnderstand="true">
         <wsu:Timestamp wsu:Id="3">


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:

               <!-- Proprietary WSIT assertion -->
               <sc:ValidatorConfiguration xmlns:sc="" 
xmlns:wspp="" wspp:visibility="private" sc:maxClockSkew="0" 


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 The default remains 5 minutes for both of them.

Technorati:Tango WSIT Glassfish Web Services

Tuesday Feb 20, 2007

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

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:

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.

Tuesday May 16, 2006

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

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




« August 2016

No bookmarks in folder