Identificar DNS origen de llamada.

[gnzsoloyo]

Tengo una app Web en C#.Net 4 MVC, esencialmente una pequeña aplicación cuyo objeto es que se la invoque pasandole parámetros y devuelve un archivo de datos para descargar o abrir en forma directa.
Funcionalmente, todoanda OK, pero me piden que cuando esté en la extranet sólo pueda ser invocada desdee una única web, dado que se podría hacer manualmente escribiendo en la barra de direcciones y llenando los parámetros que se esperan. No quieren que los usuarios puedan hacer eso.
Entonce el tema es: ¿Cómo puedo identificar desde dónde está siendo invocada?

Al principio pensé en usar el header HTTP_REFERER, pero me encontré que no siempre se puede obtener por ese medio. ALgunos sitios HTTPS no envían el dato, por lo que podría dar lugar a resultados inconsistentes.

Este es un tema recurrente, y sé que es difícil de resolver de forma efectiva.
¿Como podría hacerlo? Ideas?

[Rodrhigo]

1. Puedes enviar los datos por POST para que el usuario no manipule los datos por barra.
2. Puedes hacer una petición interna desde tu servidor A al servidor B y entregarle ese archivo al usuario, y desde el servidor B bloquear cualquier IP distinta a locahost/IP de tu servidor A.
3. puedes usar HTTP_REFERER para bloquear cualquier petición distinta de null y distinta de tu servidor(petición externa).
4. El servidor A puede solicitar internamente un código de descarga a Servidor B y enviar al usuario a servidor B con dicho codigo, Servidor B debe validarlo.
5. Puedes generar y enviar un código de descarga en función de la IP del usuario/Hora del servidor y evitas solicitarle un código al servidor B, solo debe validar IP que recibirá servidor B(la misma que A) con la formula que implementes.

[gnzsoloyo]

Bueno, finalmente optamos por una vía diferente, debido a que ninguna de las cinco posibilidades resultaba viable.
Por lo pronto, ninguna que requiriese una doble petición o la intervención de dos servidores era funcional. Como el request llegará siempre una única vez, y no debe consultar mas datos que los que recibe, entonces tenemos que bloquear los accesos ilegales sólo con lo que recibimos. De alli la idea del HTTP_REFERER.
Infortunadamente el HTTP_REFERER se nos presenta como inseguro, cuando no es que simplemente no llega por diferentes razones (servidores, firewalls, antivirus). La gente del webserver no nos puede asegurar que recibamos datos por ese camino.
Lo que hicimos es simplemente que uno de los datos críticos y de uso único nos llegue encriptado, con una herramienta de encriptación que nosotros mismos pusimos en la base, y que desde el lado de la app cliente sólo puede ser accedida por esa app. AL recibirlo lo desencriptamos y si no es un dato valido, no pasa. Y como además sólo desencriptamos por SP, no es vulnerable tampoco al sql-injection.
Funciona.