You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Rahul Mehta (JIRA)" <ji...@apache.org> on 2009/05/21 17:57:45 UTC

[jira] Created: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

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


[jira] Commented: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745077#action_12745077 ] 

Jarek Gawor commented on GERONIMO-4642:
---------------------------------------

Committed some changes to trunk (revision 805830) based on the X509SigningEncrytion_CXF.txt patch that enable X.509 signature and encryption for service references with CXF. Thanks 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: clientKeystore.jks, clientKeystore.properties, RampartToAxis2.txt, serviceKeystore.jks, serviceKeystore.properties, site.patch, usernameToken.patch, usernameToken[2].patch, UsernameToken_ServerSide[2].txt, X509SigningEncrytion_CXF.txt, X509SigningEncrytion_ServerSide_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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: site.patch

Hello Devs,

[PATCH] To add the ws-security support in Apache Geronimo (for CXF/Jetty).

With this patch, we can pull the required (ws-security) jar files  and further dependencies in the Apache CXF plugin to provide the ws-security support.

I did a small test with the UserToken successfully!

Should you have any question, please feel free to let me know.

Many Thanks for all your help.

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: site.patch
>
>   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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ 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

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


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: serviceKeystore.properties
                clientKeystore.properties

Attached serviceKeystore.properties and clientKeystore.properties

> "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: clientKeystore.properties, RampartToAxis2.txt, serviceKeystore.properties, site.patch, usernameToken.patch, usernameToken[2].patch, UsernameToken_ServerSide[2].txt, X509SigningEncrytion_CXF.txt, X509SigningEncrytion_ServerSide_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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ 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.


[jira] Commented: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740925#action_12740925 ] 

Rahul Mehta commented on GERONIMO-4642:
---------------------------------------

Deleted UsernameToken_ServerSide.txt,
Added UsernameToken_ServerSide[1].txt

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


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: clientKeystore.jks
                serviceKeystore.jks

attached keystores

> "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: clientKeystore.jks, clientKeystore.properties, RampartToAxis2.txt, serviceKeystore.jks, serviceKeystore.properties, site.patch, usernameToken.patch, usernameToken[2].patch, UsernameToken_ServerSide[2].txt, X509SigningEncrytion_CXF.txt, X509SigningEncrytion_ServerSide_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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment:     (was: UsernameToken_ServerSide[1].txt)

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


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment:     (was: UsernameToken_ServerSide.txt)

> "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: clientKeystore.jks, clientKeystore.properties, RampartToAxis2.txt, serviceKeystore.jks, serviceKeystore.properties, site.patch, usernameToken.patch, usernameToken[2].patch, UsernameToken_ServerSide[2].txt, X509SigningEncrytion_CXF.txt, X509SigningEncrytion_ServerSide_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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment:     (was: RampartToAxis2.txt)

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


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: X509SigningEncrytion_ServerSide_CXF.txt

Hello Devs,

This patch allows to set the ws-security at the service side in CXF/Jetty. This is done through by passing the properties file in the geronimo-web.xml. 

Note: please apply UsernameToken_ServerSide[2].txt patch before this  patch. This patch (X509SigningEncrytion_ServerSide_CXF.txt) might have some duplicate code of CXFEndpoint.java, as it is contained in both the patches.

But indeed David Jencks suggested a better approach for setting X509 sign/encrypt security with the use of geronimo built in security. I will move on this to figure it out.

Many Thanks to Jarek and community members for the help.

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[2].txt, X509SigningEncrytion_CXF.txt, X509SigningEncrytion_ServerSide_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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ 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[2].txt

Corrected JettyModuleBuilder part of the  UsernameToken_ServerSide[1].txt patch to get all the properties passed in geronimo-web.xml (at service side) and pass them into ServletConfiguration.

Renamed into UsernameToken_ServerSide[2].txt

PS: this patch provides the support for UsernameToken Profile at server side in (CXF and Jetty).

Thank you.
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[2].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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ 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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment:     (was: UsernameToken_ServerSide[1].txt)

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


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: RampartToAxis2.txt

Rampart classes available in the axis2 plugin code now.
added the good version of RampartToAxis2.txt

Many Thanks.
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
>
>   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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: RampartToAxis2.txt

Hello Jarek/Devs,

This patch is to bring the rampart into Axis2 for ws-security support in Geronimo (Axis2/Tomcat).

Many Thanks for your help.

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


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: usernameToken[2].patch

Hello Devs,

This patch is the second version of the usernameToken security support  for CXF in Geronimo (with the fix of correct security header exchange).

Thanks.

  

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


[jira] Issue Comment Edited: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743746#action_12743746 ] 

Rahul Mehta edited comment on GERONIMO-4642 at 8/15/09 1:45 PM:
----------------------------------------------------------------

Hello Devs,

This patch allows to set the ws-security at the service side in CXF/Jetty. This is done through by passing the properties file in the geronimo-web.xml. 

Note: please apply UsernameToken_ServerSide[2].txt patch before this  patch. This patch (X509SigningEncrytion_ServerSide_CXF.txt) might have some duplicate code of CXFEndpoint.java, as it is contained in both the patches.

But indeed David Jencks suggested a better approach for setting X509 sign/encrypt security with the use of geronimo built in security. I will move on this to figure it out.

we can use something like this in the geronimo-web.xml at the service side:

<servlet>
    <servlet-name>DoubleItServiceImpl</servlet-name>
    <ws-security-binding>
      <security-realm-name></security-realm-name>
      <property name="wss4j.in.action">Signature Encrypt Timestamp</property>
      <property name="wss4j.in.user">myservicekey</property>
      <property name="wss4j.in.keyPassword">skpass</property>
      <property name="wss4j.in.signaturePropFile">serviceKeystore.properties</property>
      <property name="wss4j.in.decryptionPropFile">serviceKeystore.properties</property>


      <property name="wss4j.out.action">Signature Encrypt Timestamp</property>
      <property name="wss4j.out.user">myservicekey</property>      
      <property name="wss4j.out.signaturePropFile">serviceKeystore.properties</property>
      <property name="wss4j.out.encryptionPropFile">serviceKeystore.properties</property>
      <property name="wss4j.out.encryptionUser">myclientkey</property>
      <property name="wss4j.out.signatureKeyIdentifier">DirectReference</property>
      <property name="wss4j.out.keyPassword">skpass</property>
      <property name="wss4j.out.encryptionSymAlgorithm">http://www.w3.org/2001/04/xmlenc#tripledes-cbc</property>
    </ws-security-binding>
  </servlet>

Jarek, should we make the <security-realm-name> tag optional in the xsd?

Many Thanks to Jarek and community members for the help.

Rahul

      was (Author: rahul.soa):
    Hello Devs,

This patch allows to set the ws-security at the service side in CXF/Jetty. This is done through by passing the properties file in the geronimo-web.xml. 

Note: please apply UsernameToken_ServerSide[2].txt patch before this  patch. This patch (X509SigningEncrytion_ServerSide_CXF.txt) might have some duplicate code of CXFEndpoint.java, as it is contained in both the patches.

But indeed David Jencks suggested a better approach for setting X509 sign/encrypt security with the use of geronimo built in security. I will move on this to figure it out.

Many Thanks to Jarek and community members for the help.

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[2].txt, X509SigningEncrytion_CXF.txt, X509SigningEncrytion_ServerSide_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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ 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.txt

Hello Devs/Jarek,

I have setup the Server side UsernameToken security in CXF/Jetty against Geronimo-2.2 based on the old patches attached on this JIRA.

I have attached the new patch named "UsernameToken_ServerSide.txt" on this JIRA, please review and apply it. Let me know if you want me to fix something in it.

I did overwrite two files namely Geronimo-2.2/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPasswordHandler.java and Geronimo-2.2/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPortMethodInterceptor.java from trunk, so you can ignore those changes which come automatically for those two files in the patch UsernameToken_ServerSide.txt

Look forward to seeing your comments on it.


Many Thanks,
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: clientKeystore.jks, clientKeystore.properties, RampartToAxis2.txt, serviceKeystore.jks, serviceKeystore.properties, site.patch, usernameToken.patch, usernameToken[2].patch, UsernameToken_ServerSide.txt, UsernameToken_ServerSide[2].txt, X509SigningEncrytion_CXF.txt, X509SigningEncrytion_ServerSide_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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment:     (was: UsernameToken_ServerSide.txt)

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


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: usernameToken.patch

Hello Devs,

This patch provides the UsernameToken security to the web service client (for CXF).
Now user just needs to specify the username token properties in the geronimo-web.xml to access the secure web service, as following:

<usertoken>

      <username>username</username>

      <password>password</password>

 </usertoken>

Below is the example of SOAP header (traced by the tcpmonitor),  with the UsernameToken property set:

REQUEST:
----------------

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soap:mustUnderstand="1"><wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-739746"><wsse:Username xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">username</wsse:Username><wsse:Password xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><ns2:sayHi xmlns:ns2="http://service.web/"><arg0>Rahul</arg0></ns2:sayHi></soap:Body></soap:Envelope
 >



RESPONSE:
-----------------

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:sayHiResponse xmlns:ns2="http://service.web/"><return>Hello Rahul</return></ns2:sayHiResponse></soap:Body></soap:Envelope>


Now, I am working on setting the username token security for the server side and X.509 certificate.

Many Thanks to Jarek for his constant help and all devs for the prompt reply.

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


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment:     (was: UsernameToken_ServerSide[1].txt)

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


[jira] Commented: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716145#action_12716145 ] 

Jarek Gawor commented on GERONIMO-4642:
---------------------------------------

Committed slightly simplified patch to trunk (revision 781648). Thanks 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
>
>   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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ 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.txt

Hello,

I am attaching a patch for the support of UsernameToken Profile (in Apache CXF/Jetty) in Apache Geronimo at server side.

Example:  User can add the following in geronimo-web.xml at server side for the same

  <servlet>
    <servlet-name>CalculatorService</servlet-name>
    <ws-security-binding>
      <security-realm-name>geronimo-admin</security-realm-name>
      <property name="wss4j.in.action">UsernameToken</property>
    </ws-security-binding>
  </servlet>

Now, I am moving for supporting the X.509 profile.

 Many Thanks to Jarek and Community.

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: site.patch, usernameToken.patch, usernameToken[2].patch, UsernameToken_ServerSide.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.


[jira] Updated: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Rahul Mehta (JIRA)" <ji...@apache.org>.
     [ 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.txt

Hello Jarek,

Modified the patch UsernameToken_ServerSide.txt

Removed the deprecated method login from ServerPasswordHandler.java. 

ContextManager.login(this.securityRealm, new UsernamePasswordCallbackHandler(username, passwd));

and added the correct ContextManager.login method, pass the null to the third parameter Configuration.

ContextManager.l.login(this.securityRealm, new UsernamePasswordCallbackHandler(username, passwd), null);

Please review the patch and apply. Look forward to hearing some feedback.

Many Thanks,
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: clientKeystore.jks, clientKeystore.properties, RampartToAxis2.txt, serviceKeystore.jks, serviceKeystore.properties, site.patch, usernameToken.patch, usernameToken[2].patch, UsernameToken_ServerSide.txt, UsernameToken_ServerSide[2].txt, X509SigningEncrytion_CXF.txt, X509SigningEncrytion_ServerSide_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.


[jira] Commented: (GERONIMO-4642) "WS-Security support for JAX-WS Web Services"

Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/GERONIMO-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731544#action_12731544 ] 

Jarek Gawor commented on GERONIMO-4642:
---------------------------------------

Rahul,

I modified your patch for web service clients and made it a bit more generic. Instead of specifying a <usertoken> element, the user can specify any number of arbitrary properties that will be set of the port using a <property> element. That way we can configure any type of properties, for ws-security or not.
To configure ws-security properties specifically, the user will need to prefix each property with "wss4j.in." (for inbound settings) or "wss4j.out." (for outbound settings). For example:
{code}
<property name="wss4j.out.action">UsernameToken Timestamp</property>
<property name="wss4j.out.user">foo</property>
<property name="wss4j.out.password">bar</property>
{code}

These changes were committed to trunk (revision 794318). Thanks for the patch!


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