¿Cómo implementan las grandes empresas sus requisitos de seguridad que están centralizados y se utilizan para impulsar lo que las personas pueden hacer (se les permite llamar a un determinado servicio web, enviar un pedido, etc.), así como para manejar la IU (botones de desactivación, menú opciones, campos de formulario individuales)?
Estoy considerando la arquitectura RBAC: Usuarios - > Roles, Roles - > Privilegios.
Las aplicaciones complejas con permisos basados en muchos campos-cuentas-usuarios-roles-cantidad-cantidad tendrían muchos, muchos "roles" y esto se complica a medida que aumenta el número de roles.
La administración de todas estas opciones posibles parece desalentadora, y mi experiencia previa es codificar esa 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 usará como punto de autenticación / autorización común para todas / todas las aplicaciones (todas .NET, pero algunas GUI y algunas orientadas a procesos).
Esto no es posible fuera de la caja debido a la organización empresarial que se encuentra alrededor de 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 las cuentas "Microsoft" y "Google". Mike puede ver las 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 proporcionar una herramienta GUI fácil de administrar para que los gerentes puedan asignar sus informes directos a los roles apropiados.
Estaba pensando en implementar esta pieza de seguridad con la siguiente API (borrador en pseudo-có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 permisos que no facilitan la administración ni el uso de este patrón.
Cualquier enlace / ideas / punteros son apreciados.
Es una tienda .NET, pero nada de lo que he visto de .NET (Membership / AzMan) nos dará la granularidad y los requisitos de delegación necesarios. La integración de ActiveDirectory / Oracle LDAP sería agradable, pero no necesaria.
El sistema antiguo (actual) utiliza LDAP para autenticar a los usuarios, pero toda la autorización se realiza internamente y se almacena en las tablas clásicas de "Usuarios, roles y derechos".