[Go-essp-tech] Proposal for running client-certificate Gateway services on separate port

[Luca Cinquini]

Hi,
	the ESG gateway exposes several services that require client- 
certificate authentication, namely:

o The data publishing service
o The user attribute service
o The token generation service

Currently these services are exposed on the same port that is used for  
standard SSL browser access (typically, port 443), which requires the  
Tomcat container to be configured with a special connection to the ESG  
database (a "realm") to verify the identity of the user holding the  
certificate, and the file web.xml file with a special security  
constraint. In my experience, such configurations are actually quite  
prone to error, and difficult to debug, and I suspect they will  
generate grief as gateways start to be deployed by more institutions.

I would suggest to switch all services that require a client  
certificate to be be exposed on a different port (for example, 444).  
For example, the URL of the publishing service would change from:

https://<gateway>/remote/secure/client-cert/hessian/publishingService
to:
https://<gateway>:444/remote/secure/client-cert/hessian/ 
publishingService

This change would have the following advantages:

o) Make the gateway installation easier to configure and debug
o) Follow "best practices" since the non-certificate requests and the  
client-certificate requests are directed to different ports
o) If needed, the "client-certificate" port can be restricted to  
specific hosts by local administrators. This can satisfy the  
requirements of allowing client certificate requests (like publishing)  
only take place from designated data nodes, while maintaining  
unrestricted access to the rest of the gateway functionality.

The drawback os this proposal is that another port needs to be enabled  
on the gateway and possibly data node machines.

Please send comments - wether you think this is a bad idea or  
something worth experimenting with.

thanks, Luca