wcf - create - rest service c#

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

Question

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

Lo siguiente es parte de mi configuración actual utilizando el enlace basicHttp 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

Antes de continuar en este camino de lucha para implementar REST sobre WCF, le sugiero que lea this publicación de Tim Ewald. Me impactó especialmente la siguiente declaración:

No estoy seguro de querer construir sobre una capa diseñada para factorizar HTTP en la parte superior de una capa que fue diseñada para factorizarla.

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 2

Aquí hay un podcast sobre cómo proteger los servicios WCF REST con el proveedor de membresía de ASP.net:

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

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 algunos buenos comentarios sobre esto en su blog de privilegios menores.

Si desea ver la compatibilidad con la autenticación WSSE con respaldo al soporte de FormsAuthenticationTicket en WCF, consulte el código fuente de BlogService .

Answer 4

Independientemente de si la comunidad tiene opiniones en contra de REST en WCF (estoy personalmente en la cerca) Microsoft ha dado un golpe, http://msdn.microsoft.com/en-us/netframework/cc950529.aspx

Answer 5

Prueba custombasicauth @ codeplex

Answer 6

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

Sin embargo, no pude poner el ejemplo en marcha.

Answer 7

ACTUALIZACIÓN 23/01/2012

Desde que escribí esta pregunta, he visto un enfoque mucho mejor para asegurar el REST, como los 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 deberá registrarse con su servicio web REST

• a) le das a este usuario una clave privada que no se debe compartir con nadie
• b) también genera una clave pública que puede pasar por el cable en texto sin formato si es necesario (esto también se utilizará para identificar al cliente)

2.) cada solicitud del usuario necesita generar un hash para firmar la 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 ser actualizada, por ejemplo)
• b.) tomas estos 3 (o lo que sea que hayas decidido) y generas un hash de 1 vía (usando hmac por ejemplo)
• c.) en la solicitud que se envía por el cable, 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) ​​necesitará 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 legítimo ya que nadie más podría saber la clave privada)

• a.) busca la clave privada de los clientes mediante la clave pública que se transfiere durante la solicitud

• b.) tome los otros params (timestamp y la carga 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 de 1 vía resultante debe coincidir con el hash enviado a través del cable, si no se envía un 400 (o el código http que considere que es una "mala solicitud")