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
