"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
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.
