This content has been marked as final. Show 5 replies
This is a know limitation with the OSB Security framework implementation, though from a product stand point this is not an issue.
As per the ws-* standards, there is no defined order of the elements in the soap headers for encryption and Oracle implementation follows this.
We had a similar issue in the past and after having opened a SR with Oracle, we realized that due to the flexible ws-* standards, this was working as expected.
But, I would loved to see Oracle provide a means to override this behavior that can help us implement solutions that might be sensitive to the order of elements in the encryption headers.
We had submitted an enhancement request for this feature in the future releases, but Oracle would only implement this if there are multiple clients that would want this feature.
And for an alternate solution, you will need to use two proxies, one which generates the encrpytion headers in the incorrect order & and one that takes this header and corrects the order.
Though this is not an optimal solution, this is how we had implemented this and as a part of the solution we used the inbuilt sb transport to avoid the overhead as much as possible.
Hope this helps.
Yes I would agree with the above response. You can apply the policy and then filter it through another proxy composite where you can apply an XSLT to reorder the header and leave the body as is. Should be able to use simple mapping to achieve this with the same schema on the input and output of the XSL.