2012-09-03 26 views
13

Estoy escribiendo una API web utilizando MVC4 que debe ser consumida por varios tipos de clientes. Quiero usar el OpenID para autenticar.Cómo integrar OpenID en la API web de MVC4

Ya he descargado el paquete DotNetOpenAuth NuGet, pero hasta ahora todos los ejemplos son para una aplicación cliente, en lugar de una API.

Mi problema es simple. Quiero que los clientes envíen una solicitud de autenticación a mi API. La API se autentica con un proveedor de OpenID. A continuación, la API establece lo que necesita para usar las etiquetas [Autorizar] a lo largo de las llamadas a la API web.

Entiendo que en las aplicaciones .NET se puede llamar a FormsAuthentication.SetCookie, pero ¿es también una solución fácil de implementar para otros lenguajes?

La pregunta en pocas palabras. ¿Cómo integro OpenID en una aplicación web MVC4 que permite el uso de la etiqueta Authorize que puede ser llamada y consumida por múltiples idiomas?

+1

Para las personas que vuelven a esto, el paquete NuGet para DotNetOpenAuth no parece estar completamente actualizado (a partir de hoy). No tiene incluido el espacio de nombres OAUTH2. En su lugar, utilice este [enlace de sourceforge] (http://sourceforge.net/projects/dnoa/). – Quickhorn

+0

Eche un vistazo a este proyecto http://weblogs.asp.net/haithamkhedre/archive/2011/03/13/openid-authentication-with-asp-net-mvc3-dotnetopenauth-and-openid-selector.aspx –

Respuesta

23

Puede confundir las funciones de autenticación y autorización. Parece que su API web necesita ambos.

Comencemos con la autorización. Cada API (es decir, una URL web a la que accede una aplicación cliente distinta de un navegador) permite el acceso anónimo o debe estar autorizada (es decir, autorización). La autorización es OAuth del dominio. OAuth (v2, presumiblemente) describe cómo un cliente autoriza una llamada a su WebAPI.

Presumiblemente, como parte del proceso de autorización, un usuario inicia sesión en su servicio. Este paso de iniciar sesión en el usuario es autenticación. Y es ortogonal a la autorización. Si autentica al usuario a través de OpenID, nombre de usuario/contraseña, certificado X.509, etc., debería ser irrelevante para la autorización de sus llamadas WebAPI. En otras palabras, sus métodos WebAPI no deberían preocuparse por la autenticidad del usuario (léase: sin vínculos OpenID). Lo que tendrán es un filtro de autorización aplicado que verifica la autorización de una solicitud entrante y la traduce a algunos datos, incluido el nombre de usuario de la cuenta que autorizó el acceso, el nivel de acceso, la identificación del usuario autorizado. clientes, etc.

lo tanto, un paso a la vez, todo el escenario podría ser algo como esto:

  1. un usuario que opera una aplicación de tercero cliente de las partes (vamos a suponer para simplificar, que esta aplicación cliente es un tercio aplicación web party) quiere usar una funcionalidad que requiera que el cliente tenga acceso a su WebAPI a nombre del usuario.
  2. El cliente necesita obtener autorización para la suplantación limitada del usuario a medida que el cliente realiza llamadas a su WebAPI. Comienzan con un redireccionamiento de OAuth 2 al punto final de autorización a su servicio. Si esto se implementa usando DotNetOpenAuth esto podría usar la clase WebServerClient.
  3. Su punto final de autorización cumple la función de un servidor de autorización OAuth 2 y, como tal, usa la clase AuthorizationServer de DotNetOpenAuth. Lo primero que hace es verificar si hay una cookie de autenticación de formularios ASP.NET incluida en la solicitud. Esta cookie es una indicación natural de si el usuario ya inició sesión en su servicio en su navegador, y si es así, de quién es ese usuario. La verificación de esta cookie es una simple llamada al Controller.User. Tenga en cuenta que su punto final de autorización es MVC en lugar de WebAPI porque su respuesta es para el navegador/usuario, no para la aplicación cliente. Supongamos que no existe tal cookie y Controller.User es nulo (o User.Identity.IsAuthenticated es false).Consulte la muestra OAuthAuthorizationServer para saber cómo implementar este punto final.
  4. Su punto final de autorización responde con un redireccionamiento a la página de inicio de sesión del usuario, que incluye un parámetro redirectUrl en la cadena de consulta que conserva la URL de solicitud de autorización completa de OAuth 2 entrante.
  5. Su página de inicio de sesión de usuario es un punto final MVC que actúa como una parte confiable de OpenID. Este punto final usa la clase OpenIdRelyingParty de DotNetOpenAuth. Tenga en cuenta que este punto final no sabe nada de OAuth 2 o de material de autorización. Simplemente autentica al usuario. Después de autenticar al usuario, redirige a la URL en el argumento redirectUrl. Consulte la muestra OpenIdRelyingPartyMvc para saber cómo hacer esto.
  6. El punto final de autorización repite su paso anterior, excepto que esta vez hay una cookie FormsAuthentication por lo que procede a mostrar una página al usuario preguntándole si desea autorizar al cliente para acceder a los datos del usuario. El usuario hace clic en sí. (cuidado: implementar XSRF y mitigaciones de clickjacking en esta página de autorización de usuario).
  7. El punto final de autorización procesa la respuesta afirmativa del usuario y llama al AuthorizationServer para crear el registro de autorización y devolver la respuesta al cliente. Uno de los resultados de esta llamada es la formulación de una respuesta de redirección al cliente que le da un código de autorización.
  8. El navegador ahora está tirando de una URL de la aplicación del cliente que le pasa el código de autorización. Luego, el cliente usa la clase WebServerClient para intercambiar el código de autorización de un token de acceso (y generalmente un token de actualización también).
  9. La aplicación de cliente ahora realiza llamadas a las URL de su WebAPI directamente, incluido el token de acceso que obtuvo a través de OAuth 2 en el encabezado Autorización de HTTP.
  10. Su WebAPI ocupa el rol del Servidor de recursos OAuth2 y el atributo de autorizar el filtro que aplica a sus métodos WebAPI para validar el token de acceso entrante OAuth 2 usa la clase DotNetOpenAuth ResourceServer para hacer su trabajo. Puede consultar el ejemplo de OAuthResourceServer, o mejor aún, David Christiansen's WebAPI sample para saber cómo hacer esto.

Esa es toda la historia. Y sí, el rol del cliente es fácil de escribir independientemente del idioma o la biblioteca que esté usando.

Por cierto, las muestras de DotNetOpenAuth a las que me refiero no se distribuyen a través de NuGet. Usted get the samples from SourceForge.

Cuestiones relacionadas