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

[Luca Cinquini]

Hi Phil,
	thanks for replying...
On Nov 24, 2009, at 1:39 AM, <philip.kershaw at stfc.ac.uk> <philip.kershaw at stfc.ac.uk 
 > wrote:

> 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?
>
Tomcat does allow you to do this with some XML configuration in  
web.xml, and infact this is exactly what happens right now:

	<security-constraint>
		<web-resource-collection>
			<web-resource-name>URL pattern for Spring Web Services with  
certificate-based authentication</web-resource-name>
			<url-pattern>/remote/secure/client-cert/*</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>group_User_role_default</role-name>
		</auth-constraint>
	</security-constraint>

But the price you have to pay is that users that access the endpoint  
must be granted a special role (group_User_role_default, in this  
case), which Tomcat verifies by using the Realm configured in  
server.xml:

      <Realm className="org.apache.catalina.realm.JDBCRealm"  
connectionURL="jdbc:postgresql://<database host>/<database name>? 
user=<database user>&amp;password=<database password>" debug="99"  
driverName="org.postgresql.Driver" roleNameCol="attribute"  
userCredCol="password" userNameCol="dn"  
userRoleTable="security.user_attribute" userTable="security.user"/>

This is exactly what I'd like to change because I found that, in  
deploying gateways, can lead to bugs that are difficult to diagnose  
and debug...
Instead, having the following additional connector in server.xml:

	<Connector SSLEnabled="true" clientAuth="false" keystoreFile="<path  
to kesytore>" maxThreads="150" port="8443" protocol="HTTP/1.1"  
scheme="https" secure="true" sslProtocol="TLS"/>

provides for a simpler configuration and easier debugging...

I recognize that opening ports is additional burden, but on the other  
hand we are already asking sys admins to open multiple ports,  
including the ports 2811 and 50000-51000 for gridftp...

Anyway, it will work either way, I am just trying to minimize grief  
for the people that will be involved...

thanks, Luca


> 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.