[
https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Mehta updated GERONIMO-4642:
----------------------------------
Attachment: X509SigningEncrytion_CXF.txt
Hello Devs,
This patch allows the "CXF/jetty client" to send/receive the signed/encrypted
SOAP messages. You need to set ws-security inside the <port> in the
geronimo-web.xml at client side for this as given below (for instance, for both
signing and encrypting)
<port>
<port-name>DoubleItPort</port-name>
<protocol>http</protocol>
<host>localhost</host>
<port>8080</port>
<uri>/doubleit/services/doubleit</uri>
<property name="wss4j.out.action">Signature Encrypt Timestamp</property>
<property
name="wss4j.out.signatureKeyIdentifier">DirectReference</property>
<property name="wss4j.out.user">myclientkey</property>
<property name="wss4j.out.encryptionUser">myservicekey</property>
<property name="wss4j.out.keyPassword">ckpass</property>
<property
name="wss4j.out.signaturePropFile">clientKeystore.properties</property>
<property
name="wss4j.out.encryptionPropFile">clientKeystore.properties</property>
<property name="wss4j.in.action">Signature Encrypt Timestamp</property>
<property name="wss4j.in.user">myclientkey</property>
<property name="wss4j.in.keyPassword">ckpass</property>
<property
name="wss4j.in.signaturePropFile">clientKeystore.properties</property>
<property
name="wss4j.in.encryptionPropFile">clientKeystore.properties</property>
</port>
you can drop encryptionPropFile and keystore in the /WEB-INF/classes folder.
Now, I will move to the server part.
Thanks to Jarek for the constant help and to community members.
Best Regards,
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: RampartToAxis2.txt, site.patch, usernameToken.patch,
> usernameToken[2].patch, UsernameToken_ServerSide[1].txt,
> X509SigningEncrytion_CXF.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.
