Rahul, A few comments. I would drop the 1) bullet since in the grand scheme of things this is a little detail and instead I would focus more on the 2) bullet.
I like the WS-SecurityPolicy idea but it might be a little too much to do at once. So I would stage things in the following way: 1) First work on the basic WS-Security support. Add support for Username Token Profile and X509 Certificate Token Profile. 2) Once 1) is working, add support for WS-SecurityPolicy 3) Once 2) is working, add support for WSSecurityFeature as described. That will probably require adding similar extensions to CXF and Axis2 first. Besides configuring WS-Security properties for web services we also want to configure the same sort of properties for Web Service references (@WebServiceRef). So that clients can also make WS-Security secured calls. Also, to make life easier, can you put this proposal onto some personal Apache wiki page (http://wiki.apache.org/general) and I think that way we could edit this together. Thanks, Jarek On Mon, Mar 30, 2009 at 8:04 PM, rahul.soa <[email protected]> wrote: > Hello Devs, > > I have written a very initial draft for gsoc "WS-Security support for > JAX-WS Web Services" project [1]. Please suggest any modifications. > Thanks to Jarek for his thoughts and immediate help. > > // Quote > > Title: WS-Security support for JAX-WS Web Services > > Abstract: > > To integrate and enable the WS-Security features of Apache Axis2 and > Apache CXF in Apache Geronimo on web services. > > Description: > > Apache Geronimo supports two JAX-WS providers: Axis2 and CXF and both > of these libraries have some WS-Security features. But these features > are not integrated/enabled in Geronimo. So the goal is to enable these > features from within Geronimo. That involves basically two things: > > 1) that the modules (i.e. WSS4J) that provide the WS-Security features > for Axis2 and CXF are installed with Geronimo, and > > 2) that the WS-Security features such as [XML Security ('XML > Signature' - allows one to send along with the message a digital > signature of it, which assures that no one modified the message > content between the sender and receiver, 'XML Encryption' -allows one > to encrypt the message body or only its part using the given > cryptography algorithm) and Tokens ('Username Tokens' - WS-Security > scenario adds username and password values to the message header, > 'Timestamps' - Timestamps specify how long the security data remains > valid, 'SAML Tokens')] can be enabled and configured on web services > via Geronimo deployment descriptors and/or annotations. For example, > given some web service that is annotated with @WebService; so to > ensure that the service only accepts WS-Security -secured messages, it > should be something like “to add @WS-Security annotation”. > > Further in detail, we can consider WS-Security policies which can be > applied to the SOAP messages that pass between web services and web > service controls. A WS-Security is controlled in WS-Security policy > files. The WS-Security policy file (WSSE file) defines the security > policy applied to the SOAP messages that pass between web services and > their clients.[1] > > So we can use something like following annotation > @WS-Security file="MyWebServicePolicy.wsse" > Example: > @WebService > @WS-Security file="MyWebServicePolicy.wsse" > public class xyz > > The @WS-Security annotation determines the WS-Security policy file > (WSSE) to be applied to (1) incoming SOAP invocations of the web > service's methods and (2) the outgoing SOAP messages containing the > value returned by the web service's methods.[1]. The attribute file in > the above mentioned annotation specifies the path to the WS-Security > policy file (WSSE file - MyWebServicePolicy.wsse) used by the web > service. > > In addition, I think we can also define some security feature > something like SecurityFeature similar to other WebService Feature(s) > such as AddressingFeature, MTOMFeature > and RespectBindingFeature > . This new feature can also have the “enabled property” like other > features that is used to store whether a particular feature should be > enabled or disabled. This type should provide either a constructor > argument > and/or a method that will allow the web service developer to set the > enabled property. The meaning of enabled or disabled is determined by > each individual WebServiceFeature. It is important that web services > developers be able to enable/disable specific features when writing > their web applications. [2] > > [1] http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html > > [2] http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html > > > //Unquote > > Any suggestion will be appreciable. > > * Please put my email id in cc if you reply to mailing list only as I > am not on the mailing list at this time. I have sent requests many > times but could not get the confirmation reply for joining the mailing > list so far. > > Many Thanks. > > Best Regards, > Rahul > > [1] http://wiki.apache.org/general/SummerOfCode2009#cxf-project >
