I just had a crazy thought, in connection with a situation in which
we're trying to figure out a way to limit web service connections to
authorized consumers.
Here's the situation: we have both a browser-based UI (for which we
definitely do NOT want to require users to have client-side certificates
installed in their browsers), and a series of web services (for which we
want to be able to restrict any given user-ID and password to
consumer-side hardware authorized for that given user-ID and password).
For situations in which a given customer's users are calling the
services from their own hardware, at their own IP address, that's not a
problem. For situations in which the web services are being consumed by
*a specific* cloud server with *a specific, permanent, IP address*, it's
not a problem: either way, we can simply authorize that IP address for
that customer's user-IDs.
But what if the services are being consumed by a cloud server that's
part of a managed, load-balanced, instance group? I know empirically
that such a box, at least if it's a Google Compute instance, calls the
services from its own external IP address.
Could it be done with something involving presentation of the public key
of a certificate, without forcing browsers accessing the UI to also do so?
Anybody have any suggestions?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
