Here is my high-level understanding of SOAP Web Services Security (WS-Security, or WSS), at least the WSS X.509 Certificate Token Profile, and how to apply it in the context of Infor M3.
WS-Security
WS-Security is a standard by the OASIS consortium to provide message encryption and digital signature, the usual security properties to prevent eavesdropping and tampering of a message. It uses asymmetric cryptography with public-private keys and digital certificates. There is an additional property which is central to WSS: the security happens at the message level, not at the transport level, i.e. the security follows the message even across proxies and deep packet inspection gateways, for end-to-end security. WSS is common for example in financial institutions that need to inspect and route a message through several nodes that can read the non-secure part of the SOAP envelope yet not reveal the secret in the message, until it reaches the appropriate destination. If a node on the path gets compromised, the security of the message is not compromised. Despite its continued use, WSS has only had few major updates in 10 years, is not considered secure [1] [2], the Internet agrees it is complicated and design-by-committee, and there is no industry momentum behind it.
SSL/TLS, on the other hand, provides similar security properties with encryption and digital signature, using public key cryptography as well, but the security happens at the transport level, i.e. before the message level, for point-to-point security only. Thus, intermediate proxies and deep packet inspection gateways are unable to reveal the message to inspect it and route it, unless they have a copy of the destination’s private key. The workaround is to setup a chain of TLS segments, but the compromise of a node on the path, would compromise the message. TLS has additional security properties such as cipher suite negotiation, forward secrecy, and certificate revocation. TLS is constantly being updated with the latest security properties, and is widely supported and documented.
I have seen WSS interfaces used at banks and credit card companies that still have ancient mainframes and old middleware, and WSS is always used in combination with TLS, with peer authentication, thus four sets of public/private keys and digital certificates.
Infor Grid
Several applications of the Infor Grid expose SOAP web services, but I could not find how to setup WS-Security at the Grid level, so I assume it is not supported at the Grid level, only at the application level; that’s OK as SOAP over HTTPS is sufficient for the Grid’s needs.
M3 Web Services (MWS)
The MWS application does have settings to configure WS-Security (X.509 Token policy); that would be useful for an external partner to call M3 with message-level security (otherwise there is always SOAP over HTTPS); I will explore this in a future post:
M3 Enterprise Collaborator (MEC)
The MEC application on the Grid does not have built-in SOAP web services. But in MEC Partner Admin the MEC developer can setup SOAP. The SOAP client Send Web Service process does not support WS-Security; this is most unfortunate as here is precisely where I want to setup the secure interfaces with the banks and credit card companies, bummer, I will have to develop my own WS-Security client in Java. On the other hand, the SOAP server WebServiceSyncIn does support WS-Security; I will explore this in a future post:
Future work
In future posts, I will:
- Explore WS-Security in MWS
- Explore WS-Security in MEC SOAP client
- Explore WS-Security in MEC SOAP server
Conclusion
That was my high level understanding of WS-Security, at least the WSS X.509 Certificate Token Profile, and how to apply it in the context of M3. I am no expert in WS-Security, but this understanding is sufficient for my needs with M3.
That’s it!
Please subscribe, comment, like, share, and come author with us.
–Thibaud
Hi Thibaud,
I successfully created a WebserviceSyncIn channel with http://localhost:21105/webservice and then created a simple webservice client using java and successfully sent SOAP request and SOAP response to this endpoint.
Now I need to expose this endpoint to the thirdparty to receive the SOAP request from them. I tried replacing the localhost of the MEC server and failed to register the endpoint. Could you please let me know what IP should be replaced by the localhost.
Thanks,
Prem
premkumar1586@gmail.com
LikeLike
Hello Premkumar. I have not explored the WebServiceSyncIn channel yet, so I do not know the answer to your questions. But if your Java SOAP client works with localhost, then it’s a simple networking problem, not a MEC problem. If your third party is on the same local network, then it shouldn’t be a problem to access the MEC server by its hostname and port number, try gradually to ping to hostname, then tcp ping (e.g. telnet) to hostname port, then tls client (e.g. cUrl, OpenSSL or Fiddler Composer) to https://hostname:port. But if your third party is on a different network segment in the same company, then you have to look at the routers, proxies, firewalls, etc. Also, if your third party is on a different company, then you have to look at DMZ, port forwarding, or VPN or something more. Ask your network colleagues. Once you finish, would you like to write a blog post about it here? I can create an author account for you. –Thibaud
LikeLike