Pregunta:
Arquitectura de seguridad: configuración para impulsar la interfaz de usuario y los privilegios (derechos), según la función, por cuenta de usuario
Leon
2011-03-07 20:41:00 UTC
view on stackexchange narkive permalink

¿Cómo implementan las grandes empresas sus requisitos de seguridad que están centralizados y se utilizan para impulsar las cosas que las personas pueden hacer (se les permite llamar a un determinado servicio web, enviar un pedido, etc.) así como para controlar la interfaz de usuario (deshabilitar botones, menú opciones, campos de formulario individuales)?

Estoy considerando la arquitectura RBAC: Usuarios -> Roles, Roles -> Privilegios.

Aplicaciones complejas con permisos basados ​​en muchos campos-cuenta-usuario individuales -role-amountThreshhold tendría muchos, muchos "Roles" y administrar esto se complica a medida que aumenta el número de roles.

Administrar todas estas opciones posibles parece abrumador, y mi experiencia previa es codificar tal lógica en la aplicación.

Ej: If (User.Roles ("IsAccounting")) {btnEditOrder.enabled = false;}

Tengo la tarea de diseñar / implementar un servicio / arquitectura de seguridad que se utilizará como punto común de autenticación / autorización para cualquier / todas las aplicaciones (todas .NET, pero algunas GUI y algunas orientadas a procesos).

Esto no es posible de inmediato debido a la organización empresarial en torno a las cuentas de los clientes y los niveles de permisos basados ​​en montos financieros.

Ejemplo: John es un usuario y puede ver y enviar solicitudes para la cuenta "Microsoft" y "Google". Mike puede ver solicitudes de "Microsoft" y "Google", pero solo puede enviar solicitudes de "Google".

El número de cuentas / usuarios es grande y variable.

Si sigo RBAC, habrá cientos de "Roles" para acomodar todos los Derechos (Privilegios) requeridos. Esto no ayuda porque el objetivo final es brindar una herramienta GUI fácil de administrar para que los gerentes puedan asignar sus subordinados directos a los roles apropiados.

Estaba pensando en implementar esta pieza de seguridad con la siguiente API (aproximada borrador en pseudocódigo):

  UserContext securityContext = Security.GetContext (userID, userPwd);  

Y el uso en la aplicación sería así: if (securityContext.RequestManager.CanSubmitRequest ("Google")) {...}

De esta manera, habría miles de estos métodos 'Can (params)' para verificar los permisos, lo que no facilita la administración o el uso de este patrón.

Cualquier enlace / idea / puntero es apreciado.

Es una tienda .NET, pero nada de lo que he visto en .NET (Membership / AzMan) nos dará los requisitos de granularidad y delegación requeridos. La integración de ActiveDirectory / Oracle LDAP sería buena, pero no necesaria.

El sistema antiguo (actual) usa LDAP para autenticar a los usuarios, pero toda la autorización se realiza internamente y se almacena en los clásicos "Usuarios, roles, derechos" tablas.

Tres respuestas:
mrnap
2011-03-07 22:51:22 UTC
view on stackexchange narkive permalink

Creo que depende en gran medida del uso final. En la parte superior de mi cabeza y sin saber mucho sobre el usuario final de su aplicación, ¿ha pensado en la autenticación basada en sesión? Básicamente, verifique sus permisos y aplique algún tipo de identificador a su sesión. De esa manera, podría otorgar permisos permitidos a las solicitudes, que deberían ser más rápidos que verificar todos los permisos de usuario en cada solicitud. Solo tenga una tabla de búsqueda para una acción y las sesiones que pueden usarla, de esa manera podría almacenar todo de manera centralizada, lo que es mucho más fácil de administrar. Solo una nota al margen, esto es simplemente una respuesta sobre la facilidad de implementación / manejabilidad / velocidad, cuanto más segura quieras que sea tu aplicación, obviamente, más sacrificarás la velocidad. Lo que realmente impulsará su implementación es averiguar el punto de equilibrio razonable entre la velocidad y la seguridad aceptables.

Publicaré una respuesta más extensa cuando tenga más tiempo hoy. .

Esta es una idea interesante. Las acciones no son sencillas, ya que hay muchas y algunas se basan en una combinación de criterios.
Steve
2011-03-07 22:59:37 UTC
view on stackexchange narkive permalink

¿Ha examinado la autenticación basada en reclamos? La idea es que adjunto a cada usuario autenticado hay una colección de reclamos, y cada reclamo representa algo sobre el usuario. Cuando el usuario está autenticado, se extrae una colección de reclamaciones para la aplicación en particular en cuestión y puede contener un conjunto arbitrario como "CanSubmitGoogleOrders" o "PurchaseLimit = $ 4000".

La aplicación en sí solo necesita conocer qué reclamos potenciales puede recibir y actuar en consecuencia si ve (o no ve) un reclamo en particular.

Esta podría ser exactamente la forma de hacerlo. En la autenticación, cree una bolsa de notificaciones (securityContext) según los roles a los que está asignado el usuario. El sistema está construido con el paradigma de denegación predeterminado que facilitaría la administración de roles jerárquicos (es decir, el rol de un Gerente establecerá todas las reclamaciones subyacentes también para obtener acceso a ellas)
AviD
2011-03-16 20:15:54 UTC
view on stackexchange narkive permalink

Este es en realidad un problema bien conocido y, lamentablemente, todavía no existen muchas soluciones empaquetadas, al menos, no son realmente buenas.

El control de acceso basado en roles es solo un compromiso entre la administración escalable y la seguridad. A menudo, esta era una buena elección, simplemente porque la alternativa era ... bueno, realmente no había muchas alternativas hasta ahora ... Siempre implicaba cantidades masivas de codificación personalizada compleja. Excepto en el caso de requisitos de seguridad bancarios o militares, ese era el camino a seguir ... pero siempre fue un compromiso en aras de hacer que la seguridad fuera manejable.

Si bien la sugerencia de @SteveS de La autenticación basada en reclamaciones es buena (para .NET puede consultar lo que se conocía como el marco de Ginebra o Windows Identity Foundation (WIF)), y definitivamente es una mejora en la dirección de más seguridad granular, realmente no ayuda a resolver el problema de la "administración escalable".

También puede mirar en la dirección de lo que se conoce (desafortunadamente) como "administración de derechos", control de acceso basado en políticas / atributos (ABAC / PBAC), control de acceso sensible al contexto, etc. .
Con ese fin, puede mirar en XACML - si bien definitivamente tiene deficiencias no triviales (incluso la próxima v3 pierde la marca ...), definitivamente es un paso sustancial en el dirección conceptual correcta. (Es solo un formato / protocolo, no está familiarizado con las herramientas estándar para hacer cumplir esto ...)

En pocas palabras, desafortunadamente, todavía no existen soluciones realmente buenas para la granularidad escalable de la administración del control de acceso. Hoy en día todavía requiere una gran cantidad de personalización, ya sea codificación personalizada en su aplicación o modificaciones extensas a algún producto de administración relacionado de forma pasiva. Tal vez alguna pequeña startup encuentre la solución a eso pronto ...
Divulgación: Estoy trabajando con una de esas startups, para hacer que la granularidad de acceso escalable sea algo que pueda usar ...

Estaba empezando a cuestionar mi inteligencia. Esto aclara el problema de la complejidad. Decidimos optar por la Autenticación basada en reclamos y aliviar la complejidad de la administración para crear un conjunto de reclamos "predeterminado" ("Roles") que se pueden anular según sea necesario por usuario. El contexto del usuario se expondrá como una bolsa de afirmaciones, pero la forma en que se produzcan esas afirmaciones se codificará a mano internamente.
¿Puede mencionar las deficiencias de la versión 3?


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 2.0 bajo la que se distribuye.
Loading...