[Go-essp-tech] Proposal for running client-certificate Gatewayservices on separate port
Luca Cinquini
luca at ucar.edu
Tue Nov 24 08:09:26 MST 2009
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>&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.
More information about the GO-ESSP-TECH
mailing list