Add WS-Security endpoint filter

Details

  • Type: Patch submission Patch submission
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0-rc3
  • Fix Version/s: 1.4.0
  • Component/s: Modules: CXF
  • Labels:
    None
  • Similar Issues:
    None

Description

This would enable a very simple way to apply security headers to inbound and outbound service invocations using the Mule security api

Issue Links

relates to

New Feature - A new feature of the product, which has yet to be developed. MULE-1181 Provide SAML Security

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ross Mason added a comment -

This can potentially get quite complex and suppling a simple solution for mule cannot be achieved before V1.0 is released

Show
Ross Mason added a comment - This can potentially get quite complex and suppling a simple solution for mule cannot be achieved before V1.0 is released
Hide
Permalink
Andrew Perepelytsya added a comment -

Apache's WSS4J now have a release available at http://www.apache.org/dyn/closer.cgi/ws/wss4j/ .

Reading the article at http://www.devx.com/Java/Article/28816/0/page/1 it seems quite feasible to incorporate WS-Security in some reasonable time.

Show
Andrew Perepelytsya added a comment - Apache's WSS4J now have a release available at http://www.apache.org/dyn/closer.cgi/ws/wss4j/ . Reading the article at http://www.devx.com/Java/Article/28816/0/page/1 it seems quite feasible to incorporate WS-Security in some reasonable time.
Hide
Permalink
Ross Mason added a comment -

XFire has support for this in the pipeline. We should keep an eye on it

Show
Ross Mason added a comment - XFire has support for this in the pipeline. We should keep an eye on it
Hide
Permalink
Jos Dirksen added a comment -

I've recently implemented a WS-Security check for one of our customers using WSS4J. Creating a filter from this won't be that hard, I'll see if I can make time for this in the next couple of days, and attach it to this issue.

Show
Jos Dirksen added a comment - I've recently implemented a WS-Security check for one of our customers using WSS4J. Creating a filter from this won't be that hard, I'll see if I can make time for this in the next couple of days, and attach it to this issue.
Hide
Permalink
Ingo Boegemann added a comment -

I written an implementation for Mule to use the Password Digest functionality of WSS4J
I attached the project. It contains the required libs for WSS4J as well as a simple echo service demonstrating the use of the functionality.

Show
Ingo Boegemann added a comment - I written an implementation for Mule to use the Password Digest functionality of WSS4J I attached the project. It contains the required libs for WSS4J as well as a simple echo service demonstrating the use of the functionality.
Hide
Permalink
Ross Mason added a comment -

Thanks for the submission Ingo. We'll take a look t it as soon as 1.3 final is out

Show
Ross Mason added a comment - Thanks for the submission Ingo. We'll take a look t it as soon as 1.3 final is out
Hide
Permalink
Marie Claire Rizzo added a comment -

Does anyone mind if I start looking into this issue?

Show
Marie Claire Rizzo added a comment - Does anyone mind if I start looking into this issue?
Hide
Permalink
Marie Claire Rizzo added a comment -

I tried implementing the WS Security specifically on Xfire, using the WSS4J Handlers to do all the verifacation work for me. However, I had to add the required handlers to the Xfire connector. This poses a problem since in this way whatever communication done over Xfire would be secured, i.e. once the handlers are set, security is no longer optional but mandatory.

A good idea at this point would be the intervention of a Security Filter. You set the filter on the endpoint you want secured and add the required handlers at run time. This is where I encountered my concrete wall. I can't seem to be able to set the handlers on the connector dynamically. Initially I was trying to use two Xfire connectors (one secured and the other one open) but one of them keeps getting overridden by the other.

Could someone please offer some pointers?

Show
Marie Claire Rizzo added a comment - I tried implementing the WS Security specifically on Xfire, using the WSS4J Handlers to do all the verifacation work for me. However, I had to add the required handlers to the Xfire connector. This poses a problem since in this way whatever communication done over Xfire would be secured, i.e. once the handlers are set, security is no longer optional but mandatory. A good idea at this point would be the intervention of a Security Filter. You set the filter on the endpoint you want secured and add the required handlers at run time. This is where I encountered my concrete wall. I can't seem to be able to set the handlers on the connector dynamically. Initially I was trying to use two Xfire connectors (one secured and the other one open) but one of them keeps getting overridden by the other. Could someone please offer some pointers?
Hide
Permalink
Marie Claire Rizzo added a comment -

For now I implemented (and committed) the Ws-Security on the Xfire Connector, which uses the WSS4J In and Out Handlers to perform the security checks. I will provide an example of how this feature can be used in the integration tests. However, I did not use filters so basically, if the connector has the handlers configured on it, it will perform the security checks, otherwise it lets everything pass.

Comments are welcomed.

Show
Marie Claire Rizzo added a comment - For now I implemented (and committed) the Ws-Security on the Xfire Connector, which uses the WSS4J In and Out Handlers to perform the security checks. I will provide an example of how this feature can be used in the integration tests. However, I did not use filters so basically, if the connector has the handlers configured on it, it will perform the security checks, otherwise it lets everything pass. Comments are welcomed.
Hide
Permalink
Holger Hoffstaette added a comment -

I've fixed the duplicate XML parser and JDK-1.5-only dependencies; please try to run your example on JDK 1.4 to verify that it really works.. :o)

Show
Holger Hoffstaette added a comment - I've fixed the duplicate XML parser and JDK-1.5-only dependencies; please try to run your example on JDK 1.4 to verify that it really works.. :o)
Hide
Permalink
Marie Claire Rizzo added a comment -

Thanks Holger. It works on JDK 1.4

Show
Marie Claire Rizzo added a comment - Thanks Holger. It works on JDK 1.4
Hide
Permalink
Holger Hoffstaette added a comment -

Excellent. Out of curiosity - any idea what would be necessary to support axis1? Does axis1 even support WS-Security or would we need axis2 for that?

Show
Holger Hoffstaette added a comment - Excellent. Out of curiosity - any idea what would be necessary to support axis1? Does axis1 even support WS-Security or would we need axis2 for that?
Hide
Permalink
Holger Hoffstaette added a comment -

blush - ignore my last question, I just read the link about wss4j.

Show
Holger Hoffstaette added a comment - blush - ignore my last question, I just read the link about wss4j.
Hide
Permalink
Marie Claire Rizzo added a comment -

I created a security filter which adds the handlers to the xfire service we need to secure. I have tested this on both inbound and outbound and it seems to be working The only problems for now seem to be coming from Saml Tokens although I think the problem is coming from the wss4j SAML implementation itself.

Now I'll see how I could adapt this filter to support axis as well as xfire.

Show
Marie Claire Rizzo added a comment - I created a security filter which adds the handlers to the xfire service we need to secure. I have tested this on both inbound and outbound and it seems to be working The only problems for now seem to be coming from Saml Tokens although I think the problem is coming from the wss4j SAML implementation itself. Now I'll see how I could adapt this filter to support axis as well as xfire.
Hide
Permalink
Marie Claire Rizzo added a comment -

Okay.. as for the progress with the WS-Security and Saml.... there are some issues with the saml verification when using WSS4J and even in Xfire's WSS4JInHandlers... at least that's how I feel. I still waiting for a reply with regards to whether I am correct in stating this from either the apache or the xfire people.

However, when implementing a new handler, extending Xfire's AbstractWSS4JHandler, I was able to fix the stuff that wasn't working properly and also enable us to get the required properties from the service properties instead of from the message context (Xfire's message context) which was being created a new in the MuleLocalChannel and thus did not have the required properties set on it. It also provided a work around for the Signed Saml Token problem. The only problem is that I feel it's too much like "copying " the existing WSS4JInHandler cause there's not that much variety to the things one has to do in the handler...

Continuing on the subject of handlers.... this might be a route of getting both Xfire and Axis1 to be ws-secured, i.e. the ws-security module won't be transport specific but will cater for both. Just a thought.

Please, I need feedback.

Show
Marie Claire Rizzo added a comment - Okay.. as for the progress with the WS-Security and Saml.... there are some issues with the saml verification when using WSS4J and even in Xfire's WSS4JInHandlers... at least that's how I feel. I still waiting for a reply with regards to whether I am correct in stating this from either the apache or the xfire people. However, when implementing a new handler, extending Xfire's AbstractWSS4JHandler, I was able to fix the stuff that wasn't working properly and also enable us to get the required properties from the service properties instead of from the message context (Xfire's message context) which was being created a new in the MuleLocalChannel and thus did not have the required properties set on it. It also provided a work around for the Signed Saml Token problem. The only problem is that I feel it's too much like "copying " the existing WSS4JInHandler cause there's not that much variety to the things one has to do in the handler... Continuing on the subject of handlers.... this might be a route of getting both Xfire and Axis1 to be ws-secured, i.e. the ws-security module won't be transport specific but will cater for both. Just a thought. Please, I need feedback.
Hide
Permalink
Marie Claire Rizzo added a comment -

Hi... at the moment I'm half way successful with the WS-Security on Axis. The problem with Axis is that it needs the wsdd deployment files... yet another piece of configuration

I have manged to use the filter to set the in handlers to tackle ws-security (same as with XFire) with requests coming into the server so the server wsdd is no longer required. However, at the moment we there is still the need of a client wsdd with hard coded properties.

Show
Marie Claire Rizzo added a comment - Hi... at the moment I'm half way successful with the WS-Security on Axis. The problem with Axis is that it needs the wsdd deployment files... yet another piece of configuration I have manged to use the filter to set the in handlers to tackle ws-security (same as with XFire) with requests coming into the server so the server wsdd is no longer required. However, at the moment we there is still the need of a client wsdd with hard coded properties.
Hide
Permalink
Marie Claire Rizzo added a comment -

I submitted the filter so I guess I can close this.

Show
Marie Claire Rizzo added a comment - I submitted the filter so I guess I can close this.

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: