[ 
https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Mehta updated GERONIMO-4642:
----------------------------------

    Attachment: UsernameToken_ServerSide[1].txt

Hello,

I missed three classes in the previous patch (UsernameToken_ServerSide.txt), so 
I am attaching the new patch for the same. (with the name 
UsernameToken_ServerSide[1].txt).

Apology for inconvenience.

Thank you so much.
Rahul

> "WS-Security support for JAX-WS Web Services"
> ---------------------------------------------
>
>                 Key: GERONIMO-4642
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-4642
>             Project: Geronimo
>          Issue Type: New Feature
>      Security Level: public(Regular issues) 
>          Components: webservices
>         Environment: Apache Geronimo, Apache CXF, Apache Axis2, Ws-Security, 
> Web Services, Java, Linux
>            Reporter: Rahul Mehta
>            Priority: Minor
>         Attachments: site.patch, usernameToken.patch, usernameToken[2].patch, 
> UsernameToken_ServerSide[1].txt
>
>   Original Estimate: 2016h
>  Remaining Estimate: 2016h
>
> To integrate and enable the WS-Security features of Apache Axis2 and Apache 
> CXF in Apache Geronimo:
> ----------------------------------------------------------------------------------------------------------------------------------------------
> 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.
> Besides configuring WS-Security properties for web services we also need to 
> configure the same sort of properties for Web Service references 
> (@WebServiceRef) so that clients can also make WS-Security secured calls.
> 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] 
> References:
> [1] [WWW] http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html
> [2] [WWW] http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to