WCF y Silverlight 4.0 en la aplicación N-Tier: autenticación de llamadas al servicio

Question

Tengo una aplicación N-Tier que se creó de la siguiente manera:
En el lado del servidor en IIS7 se encuentra una aplicación ASP.Net que expone los métodos en un Servicio WCF. Esos métodos hablan con el DB usando EF4. Los clientes escritos en Silverlight 4.0 están llamando a los métodos en el servicio WCF.

El servicio WCF expone este método:

[OperationContract] 
void DeleteItem(int i_ItemId); 

Soy nuevo en seuring servicios WCF, pero creo que estos próximos observaciones son verdaderas (corríjanme si me equivoco):

1) Si Dejo este método/servicio como está, cualquiera que sepa que mi servicio está sentado en http://www.mysite.com/myservice.svc podría simplemente abrir VisualStudio, abrir "Agregar referencia de servicio" y comenzar a hacer llamadas a DeleteItem().

2) Si trato de resolver lo anterior quitando el punto final MEX, las llamadas al servicio aún se pueden hacer utilizando alguna codificación manual.

Así que, tratando de resolver esos dos problemas, comencé a aprender sobre algunas características de seguridad incorporadas en WCF. Después de un vistazo rápido que pensé que puede utilizar la siguiente configuración de enlace por lo que se necesitan un nombre de usuario y contraseña para realizar llamadas al servicio:

<wsHttpBinding> 
    <binding name="RequestUserName" > 
     <security mode="Message"> 
     <message clientCredentialType="UserName"/> 
     </security> 
    </binding> 

Tratando de adoptar esta solución, el primero que me vino a la mente fue : Cuando un usuario inicia sesión en el cliente, el cliente usa el nombre y la contraseña del usuario como credenciales para la llamada WCF. En el lado del servidor, esas credenciales se validan contra el DB.

El problema ahora es que esas credenciales (nombre de usuario y contraseña) son, por supuesto, conocidas por el usuario, por lo que puede usarlas para llamar a DeleteItem() de la manera que ya he mencionado.

Desde aquí me ocurrió con dos soluciones:

1) en lugar utilizando usuario y contraseña como credenciales, voy a utilizar un llave codificada en el cliente. Revolver el Dll dentro del XAP podría evitar que alguien obtenga esta clave.

2) Cuando un usuario inicia sesión en el cliente, el servidor envía algún tipo de token temporal (GUID o algo), que el cliente puede usar para autenticar sus llamadas durante esta sesión de comunicación (Digamos, hasta que el usuario cierra el cliente).

Mi pregunta es:

Lo que el nivel de seguridad que ofrece la primera solución y lo difícil que necesita para trabajar con el fin de romperlo?

Si la primera solución es muy trivial de descifrar, ¿hay una forma incorporada en WCF para administrar el sistema de tokens que menciono en la segunda solución?

Se aceptan otras soluciones que puedan alcanzar el alcance.

Answer 1

No estoy seguro del nivel de seguridad que está preguntando, pero no me sentiría seguro al almacenar el nombre de usuario y la contraseña en el archivo XAP, ofuscado o no.

Puedo describir una solución que he implementado en producción.

Básicamente, protejo la aplicación con la Autenticación de formularios estándar, pero no utilizo los redireccionamientos como lo haría normalmente con ASP.NET, utilizo el Servicio web de autenticación que se incluye con la Autenticación de formularios ASP.NET. De esa forma, mi nombre de usuario pasa por los controles de Silverlight. Mi aplicación tiene una tienda de usuario con la que autentico el Servicio de autenticación.

para enganchar al servicio de autenticación, hago esto en Global.asax:

protected void Application_Start(object sender, EventArgs e) 
{ 
    AuthenticationService.Authenticating += new EventHandler<AuthenticatingEventArgs>(AuthenticationService_Authenticating); 
} 

void AuthenticationService_Authenticating(object sender, AuthenticatingEventArgs e) 
{ 
    try 
    { 
     bool authenticated = //Call your user store here. 

     e.Authenticated = authenticated; 
    } 
    catch (Exception ex) 
    { 
     e.Authenticated = false; 
    } 
    e.AuthenticationIsComplete = true; 
} 

Se podría asegurar las partes de la página web como lo hace normalmente con las formas haría con <authorization> elemento con <deny users="?">. El navegador manejará todas las cookies por usted. Si desea proteger los servicios, en Service/folder negaría usuarios no autenticados.

Este MSDN Post habla de la solución con más detalle.