Initial Draft for gsoc [WS-Security support for JAX-WS Web Services] project
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
Re: Initial Draft for gsoc [WS-Security support for JAX-WS Web Services] project
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 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/communitypro
Re: Initial Draft for gsoc [WS-Security support for JAX-WS Web Services] project
Jarek, With CXF 2.2, adding support for WS-SecurityPolicy for WSDL first cases would most likely be MUCH easier than doing "basic WS-Security support. Add support for Username Token Profile and X509 Certificate Token Profile."Basically, if the WSDL contains the policies, set a few properties and it just works. (things like the password callback and keystore information). See: http://cwiki.apache.org/CXF20DOC/ws-securitypolicy.html and also the ws-security samples in the 2.2 distribution. I believe the same may be true for Axis2/Rampart. #3 will definitely require some work in both CXF and Axis2, but that's not necessarily a bad thing. Dan On Tue March 31 2009 4:08:53 pm Jarek Gawor wrote: > 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 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 conta
Re: Initial Draft for gsoc [WS-Security support for JAX-WS Web Services] project
Thanks Dan. I was actually looking at this CXF (and Rampart) documentation and debating which would be easier or simpler to start with. And I figured that starting with WS-SecurityPolicy will require getting more parts right and more things to understand so that's why I proposed to start small(er) and work from there. Having WS-SecurityPolicy support in Geronimo would be great but I'm not concerned about that from this project point of view. I'll be happy as long as we get Username Token Profile and X509 Certificate Token Profile support in Geronimo using or not using WS-SecurityPolicy. Thanks, Jarek On Tue, Mar 31, 2009 at 4:24 PM, Daniel Kulp wrote: > > Jarek, > > With CXF 2.2, adding support for WS-SecurityPolicy for WSDL first cases would > most likely be MUCH easier than doing "basic WS-Security support. Add support > for Username Token Profile and X509 Certificate Token Profile." Basically, > if the WSDL contains the policies, set a few properties and it just works. > (things like the password callback and keystore information). See: > > http://cwiki.apache.org/CXF20DOC/ws-securitypolicy.html > > and also the ws-security samples in the 2.2 distribution. > > I believe the same may be true for Axis2/Rampart. > > #3 will definitely require some work in both CXF and Axis2, but that's not > necessarily a bad thing. > > > Dan > > > > On Tue March 31 2009 4:08:53 pm Jarek Gawor wrote: >> 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 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 t
Fwd: Initial Draft for gsoc [WS-Security support for JAX-WS Web Services] project
// Apologize, forgot to click on "Reply All". Best Regards, Rahul -- Forwarded message -- From: rahul.soa Date: Tue, Mar 31, 2009 at 11:44 PM Subject: Re: Initial Draft for gsoc [WS-Security support for JAX-WS Web Services] project To: Jarek Gawor Hello Jarek/Daniel/Devs, Thanks for your comments. I added the proposal quickly as I sent in my previous email on the following link: http://wiki.apache.org/general/rahulsoa I will keep it updating with the discussion we are having. Thanks. Best Regards, Rahul On Tue, Mar 31, 2009 at 10:08 PM, Jarek Gawor wrote: > 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 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