Re: Sandesha2 1.5 Release Candidate

[Amila Suriarachchi]

since rampart 1.5 has been released shall we do the sandesha release?

thanks,
Amila.

On Tue, Oct 6, 2009 at 9:07 PM, David Parsons1  wrote:

>
> Hi,
>
> I have created a Sandesha2 1.5 release candidate here:
>
> 
> http://people.apache.org/~parsonsd/sandesha-1.5/RC1/dist/
>
> and the M2 repository can be found here:
>
> 
> http://people.apache.org/~parsonsd/sandesha-1.5/RC1/m2_repo/
>
> This release candidate is using the Rampart 1.5 release candidate which can
> be found:
>
>  
> *http://people.apache.org/~nandana/rampart-1.5/RC1/dist/*
>
> and the M2 repository for this can be found here:
> *
>
> **http://people.apache.org/~nandana/rampart-1.5/RC1/m2_repo/*
>
>
> I will leave this available for a short period of time.  If no one finds
> any issues I'll request a vote on whether to submit it as a release of
> Sandesha2.  The Rampart 1.5 release is going to have to be cut before I can
> officially cut the Sandesha2 release so does anyone know how close this is
> to being done?
>
> Regards,
>
> Dave
>
> Dave Parsons
> Web Services Development
> INTERNAL:  David Parsons1/UK/i...@ibmgb :: DE3F20 :: 246930
> EXTERNAL:  parso...@uk.ibm.com :: (01962) 816930
> Mail Point 211, IBM Hursley Park, Winchester. SO21 2JN
>
>
>
>  --
>
> *
> *
>
> *Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> *
>
>
>
>
>
>
>
>
>
>
>  --
>
> *
> *
>
> *Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> *
>
>
>
>
>
>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Rampart basic: security processing failed (actions mismatch)

[Doughty, Michael]

Hey guys, as I mentioned in the last request I sent to the list, I was unable 
to make use the Policy-based Rampart configuration due to the malformation of 
the SOAP messages – Rampart seems to have replace all empty default namespaces 
with the parent element’s default namespace, causing  both my SOATest testing 
tool and my Axis2/Rampart based clients to be unable to parse the resulting 
contents.  In all cases, the inner elements are not recognized and the clients 
error out complaining that they were expecting different elements.

So I decided to try out the deprecated Rampart configuration model, and I 
discovered that the resulting encryption doesn’t seem to produce the same error 
in the responses.  After that, I decided to go ahead with that and replaced my 
Policy-based configurations with the basic configurations completely.  However, 
now I am running into another odd error “WSDoAllReceiver: security processing 
failed (actions mismatch)”.  The odd thing is that the service seems to be 
handling the request’s security just fine, verifying all signatures, decrypting 
the message, and then parsing the UsernameToken.  Only after going through 
every feature does it fail like this.

The “actions” I list in the InflowSecurity section do actually match what I am 
sending, so I am unsure why this is happening.  Does anyone have any ideas?  
I’d greatly appreciate your assistance as trying to get Rampart to work 
properly with my testing tool and clients has been a bit of a struggle for the 
last few weeks.  Below is the information coming from Tomcat’s console 
(including my own trace messages in the password callback handler):

Password Callback Handler called for DECRYPT: wsserver
Password Callback Handler called for USERNAME_TOKEN_UNKNOWN: admin
[INFO] Verification successful for URI "#id-32295991"
[INFO] Verification successful for URI "#id-22237361"
[INFO] Verification successful for URI "#id-14067086"
[ERROR] WSDoAllReceiver: security processing failed (actions mismatch)
org.apache.axis2.AxisFault: WSDoAllReceiver: security processing failed (actions
 mismatch)
at org.apache.rampart.handler.WSDoAllReceiver.processBasic(WSDoAllReceiv
er.java:344)
at org.apache.rampart.handler.WSDoAllReceiver.processMessage(WSDoAllRece
iver.java:86)
at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:
72)
at org.apache.axis2.engine.Phase.invoke(Phase.java:318)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq
uest(HTTPTransportUtils.java:167)
at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:1
42)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:45
4)
at java.lang.Thread.run(Thread.java:595)