Hi all,

Looking for suggestions here. Using WWC to send documents to a web server (in house) that is a document repository. When initially programmed, used a basic http call to perform all operations (these are all rest api calls):

.ioHTTP.HttpGet(lcURL,.icUserName,.icUserPassword)

The client now wants to "tighten up" their in-house security and have asked that the password not be sent in clear text to the server.

Asking the web developer, he said that the only good way is to switch to https calls for everything - and that he would need to set up a 2nd server as an Apache server to be a proxy server (it seems that the Apache server is the only supported method if you want https). The only downside from my client's perspective is that this developer estimates from 7 to 10 days work (!) to set up the proxy server and get everything working - at a fairly "decent" daily rate.

On the plus side, I don't think I would have to change any of my code - just the url which is in a table so easy to change.

My client though has asked if there is any other way to accomplish this - they don't necessarily need documents sent via https (since the documents are not transmitted anywhere else in a secure manner e.g. printing or openng on the server etc).

They just don't want me passing the password in plain text.

Thanks, Albert

HTTPS is a good first step, but I'm not sure what purpose the proxy is supposed to serve?

A better way for remote calls typically is to have a login URL to your API (or whatever) that returns you a token. You then call the login routine to get a token and you use the token on subsequent requests. That way only the single Login request holds the login actual information - everything else uses a token that's good for only a limited time. You do need to have a lookup/mapping routine that maps the token to your actual user id but that's fairly easy. Table with TokenId, user id and an expiration timestamp that is checked when authenticating.

+++ Rick ---

Albert,

It wasn't clear in your post whether the clients were inhouse or not. If they are known, perhaps you could skip the login and lock everything down the WW getipaddress().

Just a random thought.

Hi Rick,

It seems to me the reason he is suggesting a proxy server is that authentication is done against the proxy with https and then the calls are routed to the documents server? Not sure (developer is hard to get ahold of at times - email for the most part only). Here is what he said ("Nuxeo" is the documents system). If any of it rings a bell, appreciate your comments (although I realilze that this is not your problem to solve). Thanks.

*2. Authentication Best (only) real solution is enable HTTPS Two ways of enabling HTTPS in Nuxeo

a. Enable HTTPS in Tomcat 
	- tested this approach using a self-signed certificate, numerous config changes 
	- took almost a day to get all the settings just right but this is easily repeatable in production
	- enabling HTTPS does have a performance impact (but for McKellar this shouldn’t really be noticeable) 
	- still need to test across all use cases (best done in McNuxTest) and needs to include (will required your time and running through use of client)
	- WARNING: Nuxeo themselves do not recommend using Nuxeo HTTPS model - it is officially deprecated (see b. for approved approach)

b. Install Apache and reverse proxy to Nuxeo
	- run Nuxeo on a port that is only available on server
	- have Apache enabled to support HTTPS
	- Apache converts all inbound calls to local instance of Nuxeo on port 8080
	- this approach requires more server horsepower as need to install Apache web server
	- this approach typically requires a lot of tuning and testing (to ensure that all HTTP redirects work as expected
	- to install, configure and test to confirm works as expected will take 5-10 days of effort (and there may be limitations)

both approaches require create of self-signed cert 

both approaches deal with issue of open transmission of user id and password AND additionally deal with transmission of all content - HTML or attachments

It is in-house only. The user name at least needs to be passed to stamp the documents with who put them into the repository etc. So in a way we could skip passing the password. But that seems to be a step backwards as they want all their data to be more secure than not. Access is via a rest api now for the most part.

Thanks.

Sorry I can't help with this. I have no idea what Nuxeo is but I assume that's the proxy that sits in front of TomCat. But as far as your interaction is concerned the proxy is just a Web Server that forwards requests to the internal. It looks like it's a reverse proxy. To the outside that just looks like a Web Server though.

At this point I would avoid using self-signed certificates - just create LetsEncrypt certificates which should have helpers to allow you to directly create and install into Apache. I know on Windows I can install a new LetsEncrypt cert in a few minutes. I would think that that's a much better solution than locally created certificates and trying to establish a proper trust chain to use those certificates (unless that is what you are after).

+++ Rick ---

Thanks. I will definitely pass on about the LetsEncrypt certificates.