There is no point in allowing Basic Authentication in environments where users don’t have passwords , for instance when there’s single sign on set up with SPNEGO. Connections (like most IBM products) then relies on LTPA tokens for authentication.

Also, in these enterprise environments, you would generally secure the applications (meaning : using the J2EE roles in all applications in Connections, to not allow anonymous access (everywhere where it says “Everyone”, use “All Authenticated users” instead).

The challenge in this scenario is that SOME uri’s in that scenario , will not redirect you to the standard login form (Forms based authentication), but rather pop up the annoying Basic Authentication prompt.
A sample URL that will prompt for BA is for instance https://yourconnectionsserver.com/profiles/atom/profileService.do … Another is accessing a Profile picture (only if you secured the Profiles application).

When your users use a normal browser to access Connections, you’ll hardly ever see a BA prompt, because users would generally not access these urls as the initial call. So they’ll already be authenticated by other means.

But it’s a different story when you use API access to Connections - for instance to integrate Connections content into an intranet (that does not offer LTPA SSO).
In that case, it’s pretty difficult to avoid Basic Authentication prompts popping up, because it’s not very easy to catch them in the browser.

So we went with a drastic solution - disable Basic Authentication prompts completely.
This does not disable Basic Authentication, it just disables the prompt. In our specific case, this again enables the javascript code to catch the 401 HTTP response correctly, and start an authentication sequence.
The solution does not change the header when it’s a Connections server making the connections. Connections , by itself , also uses some Basic Authentication for it’s interservice requests. I don’t want to mess with these. I don’t think this is really necessary (since, again, Basic Authentication is not disabled), but still.

The solution is based on what’s written here :
https://coderwall.com/p/ca-2bq/modify-the-www-authenticate-response-header-in-apache

However, that did not exactly work for me: I had to remove the “always” keyword - otherwise the Header edit would not work.

###################  
#  
#    remove basic auth headers in the response except for the Connections nodes (incl. ccm, fileviewer, etc)  
SetEnvIf Remote_Addr ".*" REMOVEBASICAUTH  
SetEnvIf Remote_Addr "10\.*|127\..*" !REMOVEBASICAUTH  
Header edit WWW-Authenticate ^Basic NGCBasic env=REMOVEBASICAUTH  
# end half

So what these 3 lines do :

  1. Set the environment variable for all connections

    SetEnvIf Remote_Addr “.*” REMOVEBASICAUTH

  2. Remove the environment variable based on a regular expression (in this case, all ip addresses starting with 10. , and localhost). This regex should match the IP addresses of all the Connections servers (and FileNet , and FileViewer, and Cognos and …) - any server that would make calls to Connections.
    SetEnvIf Remote_Addr “10\.* 127\..*” !REMOVEBASICAUTH
  3. This line edits the WWW-Authenticate header, if it starts with “Basic” , and changes it to something else. The result is, that you would not get a prompt in the browser.

    Header edit WWW-Authenticate ^Basic ConnBasic env=REMOVEBASICAUTH

Remark on Mobile access and Desktop plugin

The Mobile Connections application do use Basic Authentication for authenticating, as does the Desktop Plugin.
However, neither one relies on the Basic Authentication prompt working correctly.