Cómo configurar servicios RESTful seguros con WCF usando nombre de usuario/contraseña + SSL

Question

Estoy buscando escribir un archivo de configuración que permita servicios RESTful en WCF, pero todavía quiero la capacidad de 'aprovechar' el proveedor de membresía para el nombre de usuario/autenticación de contraseña.

Lo que sigue es parte de mi configuración actual utilizando basicHttp binding o wsHttp w/out WS Security, ¿cómo cambiará esto con los servicios basados ​​en REST?

<bindings> 
     <wsHttpBinding> 
      <binding name="wsHttp"> 
       <security mode="TransportWithMessageCredential"> 
        <transport/> 
        <message clientCredentialType="UserName" negotiateServiceCredential="false" establishSecurityContext="false"/> 
       </security> 
      </binding> 
     </wsHttpBinding> 
     <basicHttpBinding> 
      <binding name="basicHttp"> 
       <security mode="TransportWithMessageCredential"> 
        <transport/> 
        <message clientCredentialType="UserName"/> 
       </security> 
      </binding> 
     </basicHttpBinding> 
    </bindings> 
    <behaviors> 
     <serviceBehaviors> 
      <behavior name="NorthwindBehavior"> 
       <serviceMetadata httpGetEnabled="true"/> 
       <serviceAuthorization principalPermissionMode="UseAspNetRoles"/> 
       <serviceCredentials> 
        <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"/> 
       </serviceCredentials> 
      </behavior> 
     </serviceBehaviors> 
    </behaviors> 

Answer 1

ACTUALIZACIÓN 01/23/2012

Desde que escribí esta pregunta que he visto un mejor enfoque para asegurar RESTO como servicios web en la naturaleza. Parecía complejo cuando escuché por primera vez, pero la idea es simple y en toda la web para los servicios web y otras comunicaciones seguras.

Requiere el uso de claves públicas/privadas.

1.) Cada usuario (cliente) del punto final tendrá que registrarse con su RESTO servicio web

• a.) Le dé a este usuario una clave privada que no debe ser compartida con cualquiera
• b.) También generar una clave pública que puede ir sobre el alambre en texto plano, si es necesario (esto también se puede utilizar para identificar al cliente)

2.) cada solicitud desde el usuario necesita generar un hash para firmar el solicitud

• a.) Un ejemplo de esto podría ser: clave privada + una marca de tiempo + carga cifrada (si es lo suficientemente pequeña como una simple información de usuario para actualizarse)
• b) usted toma estos 3 (o lo que sea) usted decidió) y generar un hash de 1 vía (usando hmac por ejemplo)
• c.) en la solicitud que se envía por el cable usted incluye la clave pública (para que el servidor sepa quién está intentando enviar esta solicitud), el hash que se generó con la clave privada y la marca de tiempo.

3.) el punto final del servidor (su método REST) ​​deberá generar un hash utilizando las mismas entradas utilizadas en el cliente. Este paso demostrará que tanto el cliente como el servidor conocían una clave privada que coincidía con la clave pública pasada junto con la solicitud. (Esto a su vez significa que el usuario que envía la solicitud es de fiar, ya que nadie más podía conocer la clave privada)

• a.) Las operaciones de búsqueda de los clientes clave privada por la clave pública que se pasa a lo largo durante la solicitud

• b.) Tome los otros parámetros (marca de tiempo y la carga útil codificada) junto con la clave privada que encontró en el paso anterior y use el mismo algoritmo para generar un hash de 1 vía (de nuevo hmac es lo que he visto usado en el mundo real)

• c) el hash resultante de 1 vía debe coincidir con el hash enviado a través del cable, si no se envía un 400 (o qué siempre código http que considere una "mala solicitud")

Answer 2

Antes de continuar por este camino de la lucha para poner en práctica RESTO sobre WCF, le sugiero que lea this mensaje por Tim Ewald. Yo estaba especialmente afectado por la declaración siguiente:

No estoy seguro de que quiera construir sobre una capa diseñada para factorizar HTTP en el parte superior de una capa que fue diseñado para factor de fuera.

He pasado los últimos 12 meses desarrollando material basado en REST con WCF y esa afirmación ha demostrado ser tan cierta una y otra vez. En mi humilde opinión, lo que WCF trae a la mesa se ve superado por la complejidad que presenta para hacer el trabajo REST.

Answer 3

Estoy de acuerdo con Darrel en que los complejos escenarios REST sobre WCF son una mala idea. Simplemente no es bonito.

Sin embargo, Dominick Baier tiene algo de good posts sobre esto en su blog de privilegios menores.

Si desea ver el soporte de la autenticación WSSE con el respaldo al soporte de FormsAuthenticationTicket en WCF, consulte el source code of BlogService.

Answer 4

Aquí es un podcast en la obtención de servicios WCF REST con el proveedor de pertenencia ASP.net:

http://channel9.msdn.com/posts/rojacobs/endpointtv-Securing-RESTful-services-with-ASPNET-Membership/

Answer 5

Sin importar si la comunidad tiene opiniones contrarias a descansar sobre WCF (estoy personalmente en la valla) Microsoft ha dado un golpe fuerte en ella, http://msdn.microsoft.com/en-us/netframework/cc950529.aspx

Answer 6

Sí estuvo de acuerdo con Moto, un enlace de la Starter Kit WCF es lo más parecido que vi a la autenticación de credenciales usando un cust om encabezado HTTP (http://msdn.microsoft.com/en-us/library/dd203052.aspx).

Sin embargo, no pude ver el ejemplo.

Answer 7

Trate custombasicauth @ codeplex