geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <jga...@gmail.com>
Subject Re: Initial Draft for gsoc [WS-Security support for JAX-WS Web Services] project
Date Tue, 31 Mar 2009 21:17:46 GMT
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 <dkulp@apache.org> 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 <rahul.soa@googlemail.com> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>

Mime
View raw message