during our migration to 9.12 (from 8.2 SP2 via 9.5.SP1) we are currently testing our connectivity from our external partner via Enterprise Gateway in DMZ to our internal application where the process ist residing.
We have done all prerequisites like firewall clearing, port forwarding from external to internal network.
First tests show that partner is able to reach the Enterprise Gateway on network layer but somehow we are not able to detect the incoming messages in RosettaNet/TradingNetworks nor do we see the process instances starting, which should listen to the RN-Messages.
Our Partner just reports “Access denied” errors which are not in our logs.
Service being used for accepting the messages from Partner is pub.estd.rosettaNet:receive which is configured in the TPA for this Partner.
Version is RN 7.1 SP2 Fix16 hosted on IS/TN 9.12 with Fixes ISCore Fix22 and TN Fix11.
eStandards Commons are on 7.1 with Fix15.
Any ideas what we are missing where and how to solve that?
I have already increased the log levels to WmPartnerMgr/TradingNetworks factories to check if there is something in the logs, but unfortunately I was not able to detect any relevant messages related to this issue.
try to turn on JSSE logging in both your server and Enterprise Gateway, see if you can find the TLS handshake happening.
Since the client is getting access denied, maybe it’s TLS related (their cert not trusted for example)
But I believe these should have been get logged (as log levels bumped up) in the DMZ IS or Internal IS some where related to actual error (TLS and SSL handshake issues) if the req’s are hitting the WAN/LAN transport boundaries per the troubleshooting been done right?
Looks like this was not happening in this case… strange.
Meanwhile we found out that we had to change the Mode of the internal registration port and the services under TNPartners ACL to the Allowed Services list.
Additionally we had to set the internal registration port and the external gateway port (for the partner system) to “Request Client Certificates” and map the certificate of the partner to the TN User created during the profile creation in internal server under “Configure Client Certificates”.
Currently we are struggling with authorization problems during load testing.
After setting watt.security.session.forceReauthOnExpiration to false and restarting both Servers (internal and Enterprise Gateway) we are now encountering a new issue:
Our external Partner reports “Invalid Session ID or Session Expired (401)” issues when trying to send data to us.
Somehow this working on Tuesday for few test messages without this setting, but since then it is no longer working.
Currently preparing a test with watt.net.useCookies=false as our partner was asking about cookie with expiration date in the past.
looks like we have figured it out meanwhile, but we are still checking for final confirmation.
The partner system needs to turn off the usage of cookies for this interface.
Similar to the parameter watt.net.useCookies, but for the other direction as this seems to only work when set on the client side.
I just want to summarize this thread up and finalize it.
watt.security.session.forceReauthOnExpiration should stay as “true” (the default) for security reasons.
When the “Invalid Session ID or Session Expired (401)” arises ask the client to ignore the HTTPS cookies on his server.
As our Partener is sending us a certificate for authentication instead of username/password we had to configure internal registration port and external gateway port (for outside partner) to “Request Client Certicates” and map the certificate on interal IS to the TN User defined in the Partners profile.
Additionally we had to add the services from the TNPartners ACL to the “Allowed Services” list of the internal registration port on the internal IS.
SAG Support informed us during incident handling that IS is sending a cookie with expiration date equal to Unix-basetime (01.01.1970, 00:00) after expiration of the session to inform the client to clear its cookie cache, but it looks that not all servers are handling this correctly.
