Cómo establecer un sistema de gestión de permisos en segundo plano de 0 a 1
Actualmente, el modelo RBAC más utilizado es el permiso de rol de usuario. Este modelo puede cumplir con la mayoría de los escenarios comerciales, refinar permisos complejos y también puede implementarse junto con el modelo ABAC.
El sistema tendrá varias funciones, pero diferentes funciones del módulo corresponderán a diferentes administradores de la empresa, por lo que los permisos también serán diferentes. Para asignar de manera flexible diferentes permisos a diferentes usuarios, se propone un modelo de permisos de rol de usuario. Un rol encapsula múltiples operaciones de permisos y se puede asignar directamente a los usuarios:
Si una gran cantidad de usuarios usan el mismo rol, todavía habrá mucho trabajo repetitivo para cada asignación, por lo que "grupos de usuarios" se derivan "Concepto". Al vincular un usuario a un grupo, al grupo se le puede asignar una función y todos los usuarios del grupo tienen esa función:
Del mismo modo, las funciones tienen muchos de los mismos permisos. Mantenimiento de funciones Una gran cantidad de permisos. debe ser revisado. Por lo tanto, puede agregar el concepto de "grupos de permisos" para empaquetar permisos comunes en grupos y asignarlos a roles.
A la hora de diseñar un sistema, podemos analizar en detalle problemas concretos. Los sistemas más simples no tienen por qué ser complejos. Cuanto más complejo es, más flexible es. Se deben considerar varios factores, como los escenarios comerciales reales y los costos de capacitación. Al diseñar la estructura de la tabla, se puede conservar el concepto de grupos. El nivel de diseño del producto es de 0 a 1, por lo que el diseño no es demasiado complicado.
Usuario, es decir, el concepto de cuenta. Debe tener una cuenta para iniciar sesión en el sistema. La cuenta está asociada al rol, lo que determina lo que puede ver y lo que puede operar; El rango de datos que cada cuenta puede ver también es diferente. Sí, puede configurar rangos de datos para cuentas según los atributos de campo de diferentes industrias, lo cual es control de acceso basado en atributos (ABAC).
Los permisos se pueden subdividir en permisos de campo y permisos de funciones de menú. Cuando diferentes cuentas ingresan al sistema, verán diferentes menús y funciones en el menú. Cuando ingresan a la misma página, la visualización de los campos en la página también es diferente.
Entonces, cuando diseñamos el sistema de permisos, podemos referirnos a esta forma de pensar.
5. Establezca la gestión de permisos: cree cuentas, cree roles, diseñe permisos de campo, diseñe permisos de funciones del menú y diseñe rangos de datos. Este artículo tomará el sistema de personal como ejemplo para ilustrar la construcción de autoridad.
En el sistema aislado, la lógica de registro se puede diseñar por separado y la lógica de cuenta se puede agregar en segundo plano para crear cuentas. El sistema de personal, como núcleo de la incorporación y renuncia de empleados, se puede crear automáticamente; una cuenta de inicio de sesión único para los empleados cuando son contratados exitosamente. Cuando dejes tu trabajo, tu cuenta caducará automáticamente.
Si necesita hacer referencia al concepto de grupos de usuarios, puede unirse automáticamente a un grupo de usuarios de acuerdo con algunas reglas específicas, como departamento, puesto, etc. También puede diseñar páginas mantenidas manualmente en grupos de usuarios.
Al crear un rol, puedes establecer a qué grupo de roles pertenece el rol. Si no existe el concepto de grupos de roles, puede ignorarlos. Las empresas que no pertenecen al grupo generalmente no requieren si la función se puede delegar hacia abajo, es decir, si la función puede establecer subfunciones y asignar permisos.
En términos generales, crear un rol solo requiere mantener el nombre y la descripción del rol. Para mayor complejidad, se puede introducir el concepto de grupos de roles o empoderamiento descendente, como empresas grupales.
Bajo roles se pueden asignar permisos de campo a diferentes módulos del sistema, por ejemplo, en el módulo de gestión de empleados se puede editar información básica, información laboral e información académica, mientras que en el módulo de perfil personal se puede editar. Solo se puede leer La información básica (cómo diseñar la estructura de la tabla del sistema, campos, etc.) no se explicará en detalle en este artículo, pero se explicará en otros artículos más adelante).
Ya sea que la cuenta tenga permisos de función de menú, es decir, si los permisos de interfaz relevantes están configurados en el diseño del producto, es necesario resolver la granularidad de cada función de página para que los estudiantes de I + D puedan planificar mejor la división; la interfaz.
La configuración de los permisos generales la completa el administrador del sistema, por lo que es suficiente garantizar una lógica fluida y páginas claras en los productos comerciales, que generalmente ordenan las funciones del menú y las enumeran para que los usuarios puedan aprender a configurarlas; ellos mismos. Normalmente la jerarquía es: directorio módulo-menú-función. Si el sistema interno está personalizado, es posible que no esté configurado formalmente. Por ejemplo, en la figura siguiente, primero configure el menú y las interfaces de funciones en segundo plano, y luego verifique estas interfaces en la función para formar permisos de función.
Cuando varias personas tienen los mismos menús y funciones, pero administran diferentes rangos de datos, por ejemplo, A y B son HRBP y administran la entrada y salida del equipo, pero A es responsable del departamento de producto; y B es responsable de todos los aspectos del liderazgo del equipo. En este momento, es necesario dividir diferentes rangos de datos para diferentes personas. Debido a que los principales atributos de división del sistema de personal provienen de los atributos de los empleados, al diseñar la tabla de empleados, se puede dividir en diferentes objetos (o tablas) según el negocio. Hay diferentes campos (o atributos de empleados) debajo del objeto, y luego, según el tipo de campo, se realizan diferentes juicios lógicos, por ejemplo, en el campo de formato de fecha, el juicio lógico puede ser >/≥/
Si se trata de otras industrias, se pueden dividir diferentes atributos según el tipo de campo; escenarios específicos; este es ABAC (Control de acceso basado en atributos)).
Cuando todos tienen un rango de datos, al compartir datos, como compartir datos de archivos de empleados, solo puede compartir la lógica y las fuentes de datos de las estadísticas de datos. El alcance depende de los permisos de la cuenta misma.
En general, los permisos de productos comerciales para pequeñas y medianas empresas no serán demasiado complicados, pero nunca cambiarán, y no importa cómo esté configurada la página, su esencia no cambiará. Tomemos como ejemplo DingTalk. Al establecer el alcance de la gestión, DingTalk solo admite la división según la estructura organizativa. Debido a que el módulo DingTalk HR se desarrolló relativamente tarde, al principio no había muchos campos de atributos integrados, por lo que el alcance de la gestión solo se podía dividir según la estructura organizativa. Pero básicamente es suficiente para la vida diaria.
Cuando se subdividen los permisos en personal inteligente, puede ver que bajo un solo negocio, DingTalk también se divide en diferentes módulos de personal. Diferentes módulos pueden configurar permisos de campo respectivamente, aunque ahora solo hay empleados Archivar un. módulo. Sin embargo, se puede ver que la arquitectura es básicamente la misma y que se admitirán varias extensiones más adelante.