2011-11-02 11 views
6

Tengo una aplicación C# .net que sirve tanto a los usuarios internos de la empresa como a los clientes externos. Necesito hacer una autorización detallada como quién accede a qué recurso. Por lo tanto, necesito algo así como una autorización basada en recursos o basada en atributos en lugar de una autorización basada en roles.Autorización detallada para aplicaciones web

Lo que viene a la mente es ya sea:

  1. práctica mi propio mecanismo de autorización y tablas SQL para mi aplicación .NET
  2. uso/implementar un mecanismo estándar, como un software que ha implementado XACML (por ejemplo Axiomatics)

El problema con el primer método es que no está centralizado ni es estándar, por lo que otros sistemas no pueden usarlo para la autorización.

El problema con el segundo enfoque es que es potencialmente más lento (debido a llamadas adicionales necesarias para cada recurso). Además, no estoy seguro de cuán ampliamente compatible con las aplicaciones en el mercado una autorización estándar como XACML para facilitar las futuras integraciones.

Entonces, en general ¿cuáles son las buenas prácticas para la autorización detallada para aplicaciones web que se supone que sirven tanto para usuarios internos como externos?

+0

¿Pueden los permisos de acceso expresarse como políticas (una regla general que cubre muchas situaciones) o las decisiones de compartir entre usuarios son básicamente arbitrarias? – kgilpin

+0

@kgilpin: los permisos de acceso pueden ser tanto generales como específicos. General como en "solo el grupo A puede leer facturas" y específico como en "el usuario X tiene acceso de lectura a la cuenta Alpha". – kaptan

+0

Creo que actualmente hay cierta confusión sobre qué es realmente el control de acceso basado en roles (RBAC). En su visión formal, RBAC es muy capaz de hacer lo que usted desea. Usted ha descrito dos roles: "lectores de facturas" y "lectores de cuenta Alpha". Abajo hay dos respuestas que provienen de proveedores de control de acceso basado en atributos, pero las reglas que describes anteriormente no me parecen basadas en atributos. Existe la percepción de que "RBAC no puede hacer esto", porque las personas confunden la formalidad de RBAC con algunas implementaciones bastante débiles de RBAC. – kgilpin

Respuesta

8

Definitivamente iré por una autorización externa. No significa que será más lento. Significa que tiene un control de acceso claramente separado de la lógica comercial.

Descripción general XACML es un buen camino a seguir. El TC es muy activo y las empresas como Boeing, EMC, la Administración de Veteranos, Oracle y Axiomatics son todos miembros activos.

La arquitectura XACML garantiza que puede obtener el rendimiento que desea. Dado que la aplicación (PEP) y el motor de decisión (PDP) están ligeramente acoplados, puede elegir cómo se comunican, qué protocolo utilizan, si se utilizan múltiples decisiones, etc. Esto significa que usted tiene la opción de elegir la integración que se adapta a sus necesidades de rendimiento.

También hay una interfaz PDP estándar definida en el perfil SAML para XACML. Eso garantiza un control de acceso "a prueba de futuro" en el que no está bloqueado en ninguna solución de proveedor en particular.

Control de acceso para aplicaciones web Usted puede caer simplemente en un PEP para aplicaciones web .NET utilizando HTTP Filtros de ISAPI y ASP.NET. Axiomatics tiene uno disponible para eso.

implementaciones actuales Si marca la página de clientes Axiomática, verá que tienen Paypal, Bell Helicopter, y mucho más. Por lo tanto, XACML es una realidad y puede abordar despliegues muy grandes (cientos de millones de usuarios).

Además, Datev eG, un proveedor líder de servicios financieros está utilizando la implementación .Net PDP de Axiomatics para sus servicios/aplicaciones. Como el .Net PDP está integrado en ese caso, el rendimiento es óptimo.

De lo contrario, siempre puede elegir entre los PEP disponibles para .Net que se integran con cualquier PDP, por ejemplo, un servicio de autorización XACML basado en SOAP.

Los altos niveles de rendimiento con XACML julio pasado en la conferencia Gartner "catalizador", Axiomática anunció el lanzamiento de su último producto, el Axiomática consulta inversa, que le ayuda a hacer frente a la 'mil millones desafío registro'. Se dirige al control de acceso para las fuentes de datos, así como RIA. Utiliza una solución XACML pura para que siga siendo interoperable con otras soluciones.

Como cuestión de hecho, Kuppinger Cole será el anfitrión de un seminario sobre el tema muy pronto: http://www.kuppingercole.com/events/n10058

leer el comunicado de prensa Axiomática ARQ también aquí: http://www.axiomatics.com/latest-news/216-axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services.html

3

Definitivamente buscar un drop-in de autorización módulo para su aplicación ASP.NET. No solo digo eso porque implemente sistemas de autenticación sin conexión al BiTKOO, sino porque en el pasado tuve que trabajar con implementaciones de autenticación de cosecha propia. Construir su propio sistema de autorización para una sola aplicación realmente no es un buen uso de su tiempo o recursos a menos que tenga la intención de hacer una carrera de implementación de sistemas de seguridad.

La externalización de la decisión de autorización desde su aplicación es una buena idea desde el punto de vista arquitectónico. La externalización de la decisión de authz le brinda una enorme flexibilidad para cambiar sus criterios de acceso sobre la marcha sin tener que cerrar su servicio web o reconfigurar el servidor web. El desacoplamiento de la interfaz web del motor de autenticación le permite escalar cada uno de forma independiente de acuerdo con la carga y los patrones de tráfico de su aplicación, y le permite compartir el motor de autenticación en varias aplicaciones.

Sí, agregar una llamada de red a su aplicación web agregará algo de sobrecarga a su respuesta web en comparación con no tener autorización o utilizar una base de datos local en el servidor web. Esa no debería ser una razón para no considerar la autorización externa. Cualquier producto de autorización serio que considere proporcionará algún tipo de capacidad de almacenamiento en caché para minimizar el número de llamadas de red requeridas por solicitud web o incluso por sesión de usuario en múltiples solicitudes web. En el sistema Keystone de BiTKOO, por ejemplo, los atributos de usuario pueden almacenarse en caché en el servidor web por sesión de usuario, por lo que solo hay una solicitud de red de back-end involucrada en la solicitud de la primera página como parte del establecimiento de un inicio de sesión de usuario. . Las solicitudes de página posteriores (dentro de la vida útil de las credenciales almacenadas en la memoria caché, generalmente 5 minutos más o menos) pueden ser manejadas por el servidor web sin necesidad de volver a presionar el servicio de autenticación. Esto se escala bien en las granjas de web en la nube y está construido sobre estándares XACML.

Cuestiones relacionadas