I have been trying to work with WS-STACK, v 8.0.5.0, deployed on a Websphere 7.0 Apps server. I can get my mainframe web services to work when I am using unsecured broker and RPC. However, if I create and deploy an archive (.aar) specifying user id and passwords for secure rpc and broker (using the “set connection and security parameters in mapping file” option) I get the following error when I try to call the web service. There are no errors showing in the JVM logs. I have attached my WS-STACK validation page.

axis2ns4:ServerXML Runtime Exception 2000 0087 Internal error. Caused by:javax.crypto.IllegalBlockSizeException: Input length (with padding) not multiple of 16 bytes20000087Internal error.javax.crypto.IllegalBlockSizeException: Input length (with padding) not multiple of 16 bytes
Web Services Stack Validation Page.htm (44.2 KB)

This might be a problem with the security installation of your JVM.

I found a hint that replacing the JCE files might help.

In general see Java SDK .

And Java SDK contains a link from where to get the “unrestricted jurisdiction policy files”.

Thank you, Rolf. I have tried as you suggested, implementing unrestricted jurisdiction security jars in the server runtimes and in RAD/Eclipse development environment, but the problem still occurs.
I therefore tried downloading and installing the latest version of the Eclipse-based development tool, as packaged and distributed by Software AG, includuing their default WS-STACK implementation and Tomcat test server. Exactly the same problem still occurs. I feel that the problem is actually rooted in the development tool, which is failing to encrypt the passwords at the time the mapping is deployed. The web-service response is probably the result of trying to decrypt something that is either not encrypted or is missing.

In case it helps anyone, I had the same error calling a deployed aar with a secured broker and specifying the security parameters in the soap header (exx-userID and exx-password fields).
The solution was to use encrypted passwords and not plain text passwords.
Therefore I also believe the error lies in the Designer as James described it.

Just FYI, This problem was later resolved by a fix from Software AG in response to a support reuqest that I opened.