Friday Oct 03, 2008

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.

Friday May 23, 2008

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:Password Type="">6S3P2EWNP3lQf+9VC3emNoT57oQ=</wsse:Password>
   <wsse:Nonce EncodingType="">YF6j8V/CAqi+1nRsGLRbuZhi</wsse:Nonce>

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

<sp:SignedSupportingTokens xmlns:sp="">
      <sp:UsernameToken sp:IncludeToken="">
            <sp:WssUsernameToken10 />
            <sp:HashPassword />

The testcase s17 available at\*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="">
   <sc:Validator name="usernameValidator" classname="xwss.s17.server.SampleWsitDigestPasswordValidator" />

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

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.

Tuesday Mar 04, 2008

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 alias.

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

Friday Feb 01, 2008

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 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 { 
       required useTicketCache=true; 
            KerberosServer { 
       required useKeyTab=true keyTab="/etc/krb5.keytab" doNotPrompt=true storeKey=true principal="websvc/service@INDIA.SUN.COM"; 
  2. Add following line to the script (or specify the mentioned JAVA_OPTS property):
            JAVA_OPTS="$JAVA_OPTS "$CATALINA_HOME/conf/jaas.conf
  3. Specify the following system property in your client code:${tomcat.home}/conf/catalina.policy${tomcat.home}/conf/jaas.conf

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.




« September 2016

No bookmarks in folder