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.

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.

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