database - nodejs - mongodb select fields

RBAC con nivel adicional

Question

Estoy tratando de diseñar una base de datos para RBAC con un giro (¿o quizás solo soy yo quien piensa que es un giro?). Como entiendo, RBAC usa roles y permisos para otorgar / denegar el acceso a ciertos objetos en mi sistema. Todo es agradable y claro cuando tengo solo una instancia de mi sitio y simplemente creo una función '' Main admin '', '' Secondary admin '', '' User '', etc.

Sin embargo, ¿qué sucede si tengo cuentas dentro del sistema? Entonces tengo un sistema que tiene cuentas de '' London '', '' Tokyo '' y '' Moscow ''. Ahora tendré ''Administrador principal'' para cada una de las cuentas, así como muchos ''Usuarios'' en cada cuenta. Por supuesto, los chicos de Moscú no deberían poder acceder a la cuenta de Londres. ¿Cómo lo hago? ¿Creo alguna tabla adicional que vinculará las asignaciones a las cuentas a los usuarios? ¿O agrego el accountid a la tabla de asignaciones? O tal vez debería crear múltiples roles como ''moscow_main_admin'', ''london_main_admin'', etc. ¿Cuál es el mejor enfoque para este tipo de situación?

También creo que tendré algunos usuarios que son ''Administrador principal'' para la cuenta de Londres y ''Administrador secundario'' para la cuenta de Tokio.

Planeo usar Yii con su RBAC integrado ... si eso hace alguna diferencia.

¿Cómo abordarlo?

¡Gracias de antemano!

Answer 1

Puede mantener los roles y reglas de "administrador" como ya los ha usado. Y agregue un nuevo rol para cada ciudad ''moscow'', ''london'', etc ... En su controlador, llame a checkAccess en sus métodos de acción como en el siguiente ejemplo.

public function actionEditArticle($town)
{
if(!Yii::app()->user->checkAccess($town)
Yii::app()->end();
// ... more code
}

Un método más avanzado sería extender CController en su directorio de componentes y anular el runAction($action) .

public function runAction($action)
{
if (isset($_GET[''town'']) {
if(!Yii::app()->user->checkAccess($_GET[''town'']) Yii::app()->end();
}
parent::runAction($action);
}

Answer 2

Por lo que entiendo de su pregunta, podría haber dos formas de resolver sus problemas.

El primero es mediante el uso de roles jerárquicos (herencia de roles). Aunque es más complicado de implementar y administrar, esto puede proporcionar un nivel de flexibilidad que es muy interesante.

La segunda forma es (si puede ser de interés) es algo con lo que he experimentado al intentar "extender" RBAC por razones académicas.

Lo que he hecho es permitir la definición de dos o más niveles "nombrados" para cada Rol. Entonces, dado el rol de Programador, mi implementación permite agregar niveles a un rol, como:

Programador, definición de nivel:

1. "Senior" = nivel 500
2. "Intermedio" = nivel 200
3. "Junior" = nivel 0

Entonces, cuando alguien asigna permisos a una instancia de un objeto, como un documento de especificación, se puede asignar de la siguiente manera:

"Some document" -> Programmer (nivel 300) -> puede editar "Some document" -> Programmer (nivel 0) -> puede leer "Some document" -> Programmer (nivel 500) -> delete

Esto indica que todos los programadores pueden leer el documento, pero los Juniors y los intermedios no pueden editar dicho documento por falta de autoridad de "nivel". Y solo el Programador Senior puede eliminar el documento.

Esto me permite tener 3 niveles distintos de permisos creando solo un rol único. En un sistema tradicional, tendría que crear los tres roles distintos (4 con herencia), como:

En una implementación no jerárquica:

1. Programador principal
2. Programador Intermedio
3. Programador Junior

En una implementación jerárquica:

1. Programador
2. Programador Senior (amplía Programador)
3. Programador Intermedio (extiende el Programador)
4. Programador Junior (extiende el Programador)

Obviamente, los niveles deben definirse adecuadamente como subpapel. Definir un nivel como "Analista" no sería válido ya que estos son dos roles diferentes y no un subtipo.

Answer 3

La mejor opción para su requerimiento es crear una jerarquía de grupo y grupo. Asignar rol a un grupo que indirectamente asignará a todos sus grupos secundarios. De esta forma, puede asignar un rol común al grupo principal y el rol individual al grupo individual. Entonces, en su caso, Londres, Tokio y Moscú son grupos.

Implementé esta solución a través de la herramienta de control de acceso de seguridad Visual Guard, que implementó y cubrió la mayoría de las preocupaciones de seguridad de la aplicación.

Utilicé Visual Guard para acceder a control para aplicaciones de varios inquilinos y saas en las que he usado grupos extensamente.

Haga clic aquí para leer más.