Azure ACS - Implementación de mejores prácticas

Question

Hola chicos, estamos construyendo una aplicación ASP.NET MCV 3 desde cero ejecutándose en Windows Azure. Acerca de la capa Autenticación y Autorización, estamos pensando en utilizar el Servicio de control de acceso. Revisé algunos artículos sobre ACS donde obtuve la idea básica, pero todavía tengo algunas dudas al respecto.

Según entiendo, al utilizar el ACS subcontratamos el proceso de Autenticación a uno o más Proveedores de Identidades (IP), básicamente confiamos en otro sistema (es decir, Microsoft Live ID) para autenticar a nuestros usuarios. El proceso básico es muy sencillo: en la etapa de autenticación, redirigimos (ACS lo hace) al usuario a una de nuestras direcciones IP "confiables", que redirigirá al usuario (con un token válido) al ACS y finalmente a nuestra aplicación. Aquí viene una serie de preguntas ...

Como no queremos que todos los usuarios con una cuenta de Live ID puedan acceder a nuestra aplicación, supongo que debe haber otro proceso para validar a ese usuario y verificar si está registrado en nuestra aplicación. La pregunta es ¿dónde? En el ACS o en nuestra aplicación.?

Tengo una idea sobre esto, pero no sé si es la manera correcta de hacerlo: En la etapa de registro, el sistema (nuestra aplicación web) pregunta al usuario qué IP (es decir, Live ID, Google, Facebook y nuestra aplicación.) Que quiere usar para autenticarse en la aplicación. Luego, el usuario pasa por el proceso de autenticación en el sistema IP y cuando regresa, almacenamos su nombre de usuario (nombre de usuario IP) en nuestro DB. Entonces, la próxima vez, en la etapa de autenticación podemos verificar si ese usuario está registrado en nuestro sistema.

Si la teoría anterior es correcta, eso significa en nuestra aplicación. necesitamos construir nuestro proveedor de membresía para almacenar los nombres de usuario que provienen de IP y los usuarios que eligen nuestra aplicación. Un sorbo. ¿Estoy en lo correcto? ¿Cuál es la mejor práctica para diseñar el proceso anterior?

Ahora hablemos de Autorización y "Roles". ¿Cómo funciona con ACS? ¿ACS administra múltiples roles por usuario?

De nuevo, tengo entendido que con ACS puede crear una cantidad de "Grupos de reglas" relacionados con la IP y no con un solo usuario. Si esto es correcto, ¿cómo gestionamos a los usuarios en función en nuestra aplicación? Digamos, por ejemplo, que tenemos múltiples roles y que nuestros usuarios pueden estar asociados a esos roles, ¿podemos usar ASC para administrarlo?

Las preguntas finales son: ¿ACS cubre el proceso completo de Autenticación y Autorización? ¿Todavía necesitamos usar el Proveedor de Membresía .net? ¿Cuál es la mejor práctica para cubrir nuestros requisitos?

Muchas gracias por su contribución.

Answer 1

El proceso de validación del usuario se realiza con reclamos.

Después de configurar una IP con ACS, cuando los usuarios se autentican, ACS obtendrá reclamaciones sobre el usuario autenticado desde la IP. Debe configurar las reglas en ACS para decir qué reclamaciones desea reenviar a su aplicación. También puede tralar reclamaciones en diferentes tipos, para normalizar el conjunto de reclamaciones entrantes según lo que espera su aplicación

Si desea implementar su acceso basado en roles con ACS, puede hacerlo.En este caso, un rol es solo otro reclamo que emitirá ACS, y usted implementará su aplicación para otorgar privilegios de usuario en función del reclamo de rol que reciba de ACS.

Puede configurar las reglas de ACS que mapean ciertas notificaciones de entrada de IP a las declaraciones de salida de función. ACS también tiene un servicio de administración que puede cambiar estas reglas para que pueda implementar un proceso de registro de usuario.

Las reglas de reclamación individual en ACS se relacionan con los proveedores de identidad que emiten el reclamo, pero los grupos de reglas no. Los grupos de reglas asocian a RP (sus aplicaciones). Un grupo de reglas es simplemente un grupo de reglas de transformación de notificaciones que le dicen a ACS: "para esta aplicación, aplique esta política de grupo de reglas cuando emita el token".

Los documentos de ACS tienen mucho que decir acerca de ACS configuración de reglas de notificación, tanto a través del portal web ya través del servicio de gestión ::

https://msdn.microsoft.com/library/azure/hh147631.aspx

respuesta ampliada:

Digamos que usted está usando ACS para autenticarse en una aplicación ASP.NET que está usando WIF. Debería configurar ACS para emitir un reclamo de función de "Administrador" para el usuario de Google con el correo electrónico "jdoe@gmail.com".

Ahora en su aplicación ASP.NET, WIF verá este reclamo de funciones y le permitirá controlar el acceso utilizando HttpContext.Current.User.IsInRole ("Manager") o el equivalente de web.config.

Puede gestionar estas reglas de ACS manualmente utilizando la interfaz de usuario web, o puede implementar un proceso de registro que agregue dichas reglas a ACS programáticamente utilizando el servicio de administración de ACS. Hay algunas muestras de servicios de gestión de ACS disponibles en acs.codeplex.com.

Además, el kit de entrenamiento desarrollador identidad tiene algunos ejemplos de WIF de acceso basado en roles:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14347

Answer 2

Para la parte de la pregunta acerca de la fase de registro, lo mejor que puede utilizar para identificar a los usuarios es la NameIdentifier tipo de demanda

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier.

Esto debe ser único para cada proveedor de identidad y también debe corregirse. Si usa el reclamo de dirección de correo electrónico, podría cambiar para el mismo usuario. Técnicamente podría ser posible que dos proveedores de identidad para utilizar el mismo NameIdentifier (ninguno de los unos hacia fuera-de-la-caja con SCA no) por lo que podría combinar la reclamación NameIdentifier con el tipo IdentityProvider reclamo

http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider

para garantizar la singularidad.

Para la parte sobre rol, yo diría que usar ACS para emitir reclamos de roles a partir de identidad genérica como Google sería bastante difícil de administrar utilizando las reglas de transformación de reclamos en ACS por usuario. Debería agregar una regla para cada usuario registrado, probablemente no sea factible. Creo que los grupos de reglas de ACS son más adecuados para la transformación de reclamos de roles (por ejemplo, emitidos por un ADFS federado). Su idea de hacerlo en su aplicación es una mejor en mi humilde opinión. En el código, el lugar para hacer esto usando WIF está en un ClaimsAuthenticationManager personalizado.Usted anula su método Authenticate y según el reclamo NameIdentifier del principio entrante, busca en su almacén de datos de membresía y crea un nuevo IClaimsPrinciple según los roles que están en su base de datos de membresía (es decir, agrega un reclamo de función para cada función) es en).

A continuación, tome su decisión de autorización en un ClaimsAuthorizationManager personalizado. Hay algunas buenas muestras e información sobre esto en la web. Usted puede comenzar en

http://msdn.microsoft.com/en-us/library/ee748497.aspx