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

[philip.kershaw at stfc.ac.uk]

Hi Luca,

I think it's a bad idea - sorry ;) ...

It can be a pain to arrange with administrators to get extra ports opened in organisations' site firewalls.  For us and I'm sure other institutions too this admin is somewhat removed from our own department and it inevitably leads to problems.

Can you not restrict the client certificate authentication function by URI instead of by port number? E.g.

https://<gateway>/myauthentication/

https://<gateway>/myauthentication/sslclientcert/

Both are exposed over the same port 443 but only the second expects to receive a client certificate.  The server side middleware applies a filter to achieve this: apply client certificate authentication if path matches '/myauthentication/sslclientcert/'.  There must be some straightforward way to do this with Tomcat surely and without it getting too complicated?

Cheers,
Phil



> -----Original Message-----
> From: go-essp-tech-bounces at ucar.edu 
> [mailto:go-essp-tech-bounces at ucar.edu] On Behalf Of Luca Cinquini
> Sent: 23 November 2009 21:00
> To: go-essp-tech at ucar.edu; esg-gateway-dev at earthsystemgrid.org
> Subject: [Go-essp-tech] Proposal for running 
> client-certificate Gatewayservices on separate port
> 
> 
> 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
_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
-- 
Scanned by iCritical.