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

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:

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.

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:

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

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

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:

    <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

About

ashutoshshahi

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
Blogroll

No bookmarks in folder