HTTP/1.1 500 Internal Server Error | GWWS_CAT:1019: Security Error: Authentication Failed.

Birger Cohrs

We are migrating Tuxedo/SALT-systems from Tuxedo/SALT 12.1.3 to Tuxedo/SALT 12.2.2. In the new environments using Tuxedo/SALT 12.2.2 we encounter

HTTP/1.1 500 Internal Server Error

and

GWWS_CAT:1019: Security Error: Authentication Failed.

in the ULOG files for any SOAP inbound service calls and we never reach the backend Tuxedo-systems.

In the corresponding current environments using Tuxedo/SALT 12.1.3 we do not encounter the above messages in the ULOG files and we always reach the backend Tuxedo-systems.

I have created a formal Oracle Support Service Request that are being taken care of since a couple of days. But in the meantime, while Oracle is working on a solution, I thought it might be a good idea to let the community be part of the game and share the joy... ;-)

Anyone having a clue what might be the problem despite the limited information supplied?

Thanks a lot in advance for any information that can lead me in the right direction!

Kind regards,

Birger Cohrs (The Swedish Tax Agency)

Birger Cohrs

I have finally obtained the solution from Oracle via Oracle Support. As the problem is functionally directly impeding I decided to share the solution with you, the community. If in trouble, you will hopefully find this post and solve the problem without hassle.

The basic problem is in a changed implementation, as far as I know introduced in Tuxedo/SALT 12.2.2, of the authentication functionality when using a custom AUTHSVR and thus a custom AUTHSVC. When leaving the custom AUTHSVC you must supply a NULL-pointer as the third argument to the tpreturn function to get the traditional Tuxedo/SALT appkey-related authentication. If you use something like

        tpreturn(TPSUCCESS, appkey, NULL, 0, 0);

the authentication in Tuxedo/SALT 12.2.2 will work the same as in Tuxedo/SALT 12.1.3.

As far as I know, the changed implementation is undocumented.

For reference, the following links might be of interest:

        Oracle Tuxedo 12c Release 2 (12.2.2) Release Notes

                https://docs.oracle.com/cd/E72452_01/tuxedo/docs1222/relnotes/relnotes.html

        ATMI C Function Reference - Section 3c - C Functions - tpreturn(3c)

                https://docs.oracle.com/cd/E72452_01/tuxedo/docs1222/rf3c/rf3c.html#1023041

Kind regards,

Birger Cohrs (The Swedish Tax Agency)

Birger Cohrs

I have finally obtained the solution from Oracle via Oracle Support. As the problem is functionally directly impeding I decided to share the solution with you, the community. If in trouble, you will hopefully find this post and solve the problem without hassle.

The basic problem is in a changed implementation, as far as I know introduced in Tuxedo/SALT 12.2.2, of the authentication functionality when using a custom AUTHSVR and thus a custom AUTHSVC. When leaving the custom AUTHSVC you must supply a NULL-pointer as the third argument to the tpreturn function to get the traditional Tuxedo/SALT appkey-related authentication. If you use something like

        tpreturn(TPSUCCESS, appkey, NULL, 0, 0);

the authentication in Tuxedo/SALT 12.2.2 will work the same as in Tuxedo/SALT 12.1.3.

As far as I know, the changed implementation is undocumented.

For reference, the following links might be of interest:

        Oracle Tuxedo 12c Release 2 (12.2.2) Release Notes

                https://docs.oracle.com/cd/E72452_01/tuxedo/docs1222/relnotes/relnotes.html

        ATMI C Function Reference - Section 3c - C Functions - tpreturn(3c)

                https://docs.oracle.com/cd/E72452_01/tuxedo/docs1222/rf3c/rf3c.html#1023041

Kind regards,

Birger Cohrs (The Swedish Tax Agency)