Thank you for raising those important points about potential vulnerabilities when using localhost and SSL certificates for secure communication. You make some valid arguments that require robust mitigation strategies.
Regarding DNS spoofing, securing DNS servers through methods like DNSSEC or using trusted local servers is crucial, but needs to happen at the system administration level. Individual applications can't fully protect against compromised DNS on their own.
Similarly, safeguarding private keys in application binaries is vital yet also relies on proper operating system permissions and hardening to prevent unauthorized access. If an attacker can already access arbitrary files on the host, then isolating sensitive data becomes exceedingly difficult.
Ultimately, defense in depth with strong system-level security is essential for any security-critical application. And OS security is the foundation on which application security relies.
Original Message:
Sent: Fri July 28, 2023 06:24 AM
From: Adrian Osterwalder
Subject: Edit Service Client - SAML2 SSO with Navigator
Hi Jian Sun,
- The mapping between localhost.ibm.net and 127.0.0.1 is all about DNS. If an attacker can modify these DNS requests by i.e. DNS poisoning or DNS hijacking, requests to localhost.ibm.net can be directed to another IP. This is not just a theoretical attack vector.
- SSL certificates are based on asynchronous encryption keys, in other words on a private and a public key. If the private key falls into the hands of a stranger, he can use it to set up a server pretending to be "localhost.ibm.net".
Since the private key must be contained in the binary files of the edit service in order to start the included web server, it can be extracted from them. Thus, malware can be programmed to impersonate Edit Service on a compromised device. Or, in connection with the first attack vector, even build a completely outsourced system that can then access the data provided by ICN. This is also a realistic and not just theoretical attack scenario.
So if you think that a TLS encrypted communication to a fqdn which is normally mapped to 127.0.0.1 is enough to harden this process, you are wrong.
------------------------------
Adrian Osterwalder
Original Message:
Sent: Fri July 28, 2023 05:28 AM
From: JIAN SUN
Subject: Edit Service Client - SAML2 SSO with Navigator
Hi Adrian,
The Edit service client launches an HTTP server at localhost.ibm.net, which is mapped to 127.0.0.1, ensuring that all browser requests are directed to localhost. This communication channel is further secured by an SSL certificate, ensuring the entire process is kept secure.
------------------------------
JIAN SUN
Original Message:
Sent: Fri July 28, 2023 05:03 AM
From: Adrian Osterwalder
Subject: Edit Service Client - SAML2 SSO with Navigator
Hi Jian Sun,
When I read in the context of authorization data: "We updated Edit client's SSL certificate from NES 3.0.13-IF001 because of SSL certificate refresh and that requires all the customers upgrade their Edit client to that version or later" alarm bells start ringing for me.
I hope that you have a good understanding that you can ensure, that the ICN does not send the authorization data to any malware or by a man-in-the-middle attack (i.e. by hacked DNS) which has extracted the private key out of the edit service! --> https://letsencrypt.org/docs/certificates-for-localhost/
I'm really interested to know how you hardened this process.
------------------------------
Adrian Osterwalder
Original Message:
Sent: Thu July 27, 2023 09:17 PM
From: JIAN SUN
Subject: Edit Service Client - SAML2 SSO with Navigator
Hi Paul,
1. Yes, ICN and Edit client must both upgrade to 3.0.14 in order to use this new feature since we have code change both on server and client side.
2. Edit client 3.0.14 is compatible with ICN server 3.0.11 but this new feature cannot be used.
3. No, we don't have any SSO behavior changes in NES 3.0.13-IF001. We updated Edit client's SSL certificate from NES 3.0.13-IF001 because of SSL certificate refresh and that requires all the customers upgrade their Edit client to that version or later. Here is the tech note about this change: https://www.ibm.com/support/pages/node/6123603
4. No, that does NOT mean ANY IdP server with uses SAML2 would be such a special case. The key point is the custom IDP server uses token exchange mechanism. With this mechanism, the application authentication token cannot be shared with client application(Edit client). You can read the IdP's documentation - The documentation should indicate if token exchange is supported and how it is implemented.
------------------------------
JIAN SUN
Original Message:
Sent: Thu July 27, 2023 02:40 PM
From: Paul de Jong
Subject: Edit Service Client - SAML2 SSO with Navigator
In the meantime we found out (by analyzing the behavior in detail by one of our developers) that for the new feature changes in 3.0.14 have been made by IBM to the Navigator application as well as to the NES. So for being able to use the new feature it would be necessary to install Navigator 3.0.14 as well as NES 3.0.14. Could you confirm this?
In our customers environment Navigator 3.0.11 is deployed. Customers strategy is to only use LTSR versions. So in our first approach we tested the new feature with Navigator 3.0.11 with NES 3.0.14. Because according the compatibility matrix this combination is supported we thought this would work. But it didn't.
As using Navigator 3.0.14 is no issue for the customer (not LTSR) we assume that for customers new SSO requirement we probably have to take a closer look to the SSO behavior of NES 3.0.13-IF001. We've been informed that in the context of another Filenet P8/Navigator application from our customer a change regarding SSO behavior between Navigator and NES (use of common session cookie?) has been initiated by an IBM Consultant.
Question to the in the What's New Section listed special cases where authentication is still required from the Edit Service client: what is exactly meant with the first bullet? Would that mean that ANY IdP server with uses SAML2 would be such a special case?
Thanks for your support!
------------------------------
Paul de Jong
DXC Switzerland GmbH
Original Message:
Sent: Wed July 26, 2023 04:05 PM
From: RUTH Hildebrand-Lund
Subject: Edit Service Client - SAML2 SSO with Navigator
There isn't a whole lot to say about the new feature...
- With this authentication improvement, once the user successfully authenticates through ICN web, he is no longer required to authenticate again when using the Edit Service client.
- This feature enhancement applies to both Single Sign-On (SSO) environments and non-SSO environments for Edit Services.
And as noted in the What's New section, these are the special cases where authentication is still required from the Edit Service client.
- A custom Identity Provider (IdP) server is used, which applies a token exchange mechanism during authentication.
- When the Edit Service client is started after the user already authenticated in IBM Content Navigator from the browser. In this situation, the user needs to refresh the browser page to allow the web to send the authentication token to the Edit client again. If the user does not refresh the browser, the Edit client resorts to the previous method of authentication and opens an authentication window.
- A custom certificate is used and the password for the custom certificate is stored in the IBM Content Navigator database. In this case, the Edit client needs to retrieve the custom certificate password from the IBM Content Navigator database upon launch. This retrieval process requires authentication.
- A user has unsaved document changes to the local workstation that results from a lost network connection or from other reasons. The network becomes online and tries to upload the unsaved changes.
------------------------------
RUTH Hildebrand-Lund
Original Message:
Sent: Tue July 25, 2023 07:55 AM
From: Paul de Jong
Subject: Edit Service Client - SAML2 SSO with Navigator
According information from one of our customers IBM improved the behavior of Edit Service Client SSO in NES 3.0.13-IF001 from Jan 26th 2023 (use of common cookie Navigator and NES…).
According "What's new in IBM Content Navigator 3.0.14" there is since 3.0.14 a new authentication behavior of the Edit Service client (Edit Service client does not require users to authenticate again if they already authenticated through the IBM Content Navigator browser). What does this mean? Have there been additional changes to the SSO behavior since NES 3.0.13-IF001? If yes: what has changed?
Is there any documentation available about the SSO behavior of Edit Service Client?
------------------------------
Paul de Jong
DXC Switzerland GmbH
------------------------------