acceso basado en función de los métodos

Question

Estoy sistema que utiliza el acceso basado en roles a los diferentes métodos en las clases de ejecución. Por ejemplo, para realizar cualquier acción que necesito para comprobar si el usuario que lo utiliza puede hacerlo.

Puedo escribir en cada método:

if(User.IsInRole ...) {
} else {
return ... throw ... whatever
}

Yo estaba pensando en la automatización de este proceso, por ejemplo, mediante la adición de atributos de estos métodos o tal vez alguna otra solución?

Answer 1

Tome un vistazo a 'programación orientada a aspectos' (AOP) bibliotecas - y las respuestas a esta pregunta StackOverflow. Puede utilizar AOP para añadir el código de comprobación de papel automáticamente.

Answer 2

Como siempre y cuando utilice directores cosas ya están allí ...

[PrincipalPermission(SecurityAction.Demand, Role = "A role available on your principal")]
public void Foo()
{
  // Will throw an exception if the principal does not have the required role
  // Otherwise the method will execute normally
}

Answer 3

Hacer el cheque una vez en el tiempo de construcción, y un tiro (o NULL regreso de la fábrica) si no se cumple la condición de seguridad. A partir de entonces, la celebración de una referencia a un objeto determinado modelo es prueba suficiente de que ha aprobado la comprobación de seguridad en un momento anterior. Si está preocupado de que esto podría causar TOCTTOU problemas, asegúrese de que estos objetos se vuelven inutilizables al final de un concepto definido por la aplicación de "turno" (por lo general la transacción de base de datos); esta es una práctica bien de todos modos.

Este enfoque de la seguridad se llama disciplina capacidad . Piense en sus objetos como cajas que tienen alguna autoridad dentro de ellos (en sus variables privadas). Pulsando los botones de la caja, sólo se puede ejercer una fracción adaptada abajo de esta autoridad en las formas en que el programador del objeto que permite a.

Por ejemplo, digamos que usted está escribiendo una aplicación de calendario con un servidor SQL. No es el objeto SQLTransaction, que no sobrevivirá a la transacción (según más arriba), pero todavía tiene todos los derechos a todas las tablas que utiliza la aplicación. Esa es una gran cantidad de energía que usted no quiere que se pasa alrededor de los usuarios de la API (explícitamente o por error, pensar en la inyección de SQL). En lugar de entregar a cabo objetos User que el modelo de la autoridad para escribir sólo para la fila de ese usuario en la tabla de usuarios; También puede crear un User, leer, actualizar objetos Appointment de borrado, que representan de manera similar autoridad limitada en la tabla de Nombramientos.

Para mantener RBAC a través de su API, se debe asegurar que el siguiente espera:

1. Sólo los usuarios legítimos puedan obtener acceso al objeto User que los representa. Aquí es donde se cablea el sistema de autenticación en el constructor User;
2. Los objetos User no fuga autoridad , es decir, que tiene que auditar su API para asegurarse de que mediante el ejercicio de las llamadas de método en un User (o cualquier objeto relacionado regresan, de forma recursiva) no puede leer ni alterar los recursos que no pertenecen a este usuario. Aquí es donde se puede aplicar la faceta patrón - por ejemplo, los rendimientos User.GetAppointments() casos reales Appointment para las citas creadas por este usuario, pero sólo lectura envoltorios de los creados por otra persona.