## Antecedentes En el [artículo anterior](/ciam-101-intro-authn-sso/), introdujimos el concepto de autenticación (AuthN) y autorización (AuthZ), junto con algunos términos dolorosos de cabeza: Identidad, Organización, Inquilino, etc. La Organización y el Inquilino son geniales para agrupar Identidades, pero conducen a una democracia absoluta: todos pueden hacer cualquier cosa en este sistema. Mientras que la utopía aún es un misterio, echemos un vistazo a la gobernanza del acceso: Autorización (AuthZ). ### ¿Por qué necesitamos autorización? La Autorización (AuthZ) responde a la pregunta “¿Qué puedes hacer?” Notion es un gran ejemplo. Para cada página que posees, puedes elegir mantenerla privada, accesible solo para ti, o compartirla con amigos, o incluso con el público. O, para una librería en línea, quieres que todos puedan ver todos los libros, pero que los clientes solo puedan ver sus propios pedidos, y que los vendedores solo puedan gestionar los libros en sus tiendas. AuthZ y AuthN son componentes esenciales de un modelo de negocio complejo. A menudo van de la mano; AuthZ verifica el acceso de un usuario, mientras que AuthN autentica las identidades. Ambos son necesarios para un sistema seguro. ## El modelo básico de autorización Aquí está uno de los modelos AuthZ más comunes: Si **IDENTIDAD** realiza **ACCIÓN** en **RECURSO**, entonces **ACEPTAR** o **DENEGAR**. En el ejemplo de Notion, el modelo es **PERSONA** realiza **VER** en **PAGINA.** Si la página es privada: - Recibirás **ACEPTAR** al realizar **VER** en tu **PAGINA**. - Todos los demás deberían recibir **DENEGAR** al realizar **VER** en tu **PAGINA**. Basado en el consenso, la industria desarrolló varias tecnologías de autorización, como el Control de Acceso basado en Roles (RBAC), el Control de Acceso basado en Atributos (ABAC). Hoy nos centraremos en el [modelo RBAC de NIST](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) Nivel 1: RBAC Plano. ## Control de Acceso basado en Roles El modelo RBAC de NIST dejó muchas cosas abiertas para proporcionar flexibilidad y adaptabilidad a diversos escenarios. Logto ahora adopta la definición de Nivel 1 con un concepto adicional "Resource" (es decir, Recurso de API). Ampliemos el ejemplo de la librería. Digamos que tenemos muchos clientes, pero solo un vendedor: - Los clientes pueden ver y pedir libros, así como ver sus propios pedidos. - El vendedor puede ver, crear, y eliminar libros, y gestionar los pedidos de los clientes. ### Definir recursos En Logto, un recurso (es decir, Recurso de API) generalmente representa un conjunto de entidades o ítems, dado que se requiere usar una URL válida como indicador. Por lo tanto, definimos dos recursos: - Libros: `https://api.bookstore.io/books` - Pedidos: `https://api.bookstore.io/orders` Una de las ventajas de hacer cumplir el formato de URL es que puede asignar a una dirección real de su servicio de API, lo que mejora la legibilidad y reconocibilidad al integrarse con otros componentes en el sistema. 🤔 Los recursos deben dividirse de acuerdo a las necesidades del negocio. No hay acciones únicas para todos; la decisión se debe tomar caso por caso. El ejemplo en este artículo divide Libros y Pedidos, lo que puede ser adecuado para microservicios, pero no para una arquitectura monolítica. ### Definir permisos Ya que introdujimos el concepto de recurso, en Logto, también hacemos cumplir que los permisos deben pertenecer a un recurso, a la inversa, los recursos pueden tener permisos. Añadamos algunos permisos a los recursos: - Libros: `leer`, `crear`, `eliminar` - Pedidos: `leer`, `leer:yo`, `crear:yo`, `eliminar` Aunque no hay requisito del nombre de un permiso, tenemos la convención como abajo: ``` [:] ``` While `` es requerido para describir un permiso, `:` puede ser ignorado para describir un objetivo general, es decir, a todas las entidades o ítems en el recurso. Por ejemplo: - El permiso `leer` en el recurso Libros significa la acción de leer libros arbitrarios. - El permiso `crear:yo` en el recurso Pedidos significa la acción de crear pedidos que pertenecen al usuario actual. ### Definir roles En resumen, un rol es un grupo de permisos. Creemos dos roles `cliente` y `vendedor` y asignemos permisos a ellos como se muestra a continuación: ```mermaid erDiagram Role-Customer { permission Books "read" permission Orders "read:self" permission Orders "create:self" } Role-Seller { permission Books "read" permission Books "create" permission Books "delete" permission Orders "read" permission Orders "delete" } ``` Puedes notar que la asignación permiso-rol es relaciones de muchos-a-muchos. ### Asignar roles a usuarios Al igual que la asignación de roles-permisos, la asignación de usuarios-roles también es una relación de muchos a muchos. Por lo tanto, puedes asignar múltiples roles a un solo usuario, y un solo rol puede ser asignado a múltiples usuarios. ### Conectar los puntos Aquí hay un diagrama completo de relaciones para el modelo RBAC de Nivel 1 en Logto: ```mermaid erDiagram User }|--|{ Role : mapas Role }|--|{ Permission : mapas "API Resource" ||--|{ Permission : contiene ``` En el modelo RBAC, los permisos siempre son "positivos", lo que significa que el juicio de autorización es simple: si un usuario tiene el permiso, entonces acepta; de lo contrario, rechaza. Supongamos que Alice tiene el rol de `vendedor`, Bob y Carol tienen el rol de `cliente`. Describiremos acciones en lenguaje natural primero, y las transcribiremos al formato estándar de autorización: **IDENTIDAD** realiza **ACCIÓN** en **RECURSO**, finalmente dando la conclusión. - Alice quiere agregar un nuevo libro para vender: - El usuario Alice realiza `crear` en el recurso Libros (`https://api.bookstore.io/books`). - Como a Alice se le ha asignado el permiso de `crear` Libros según su rol de `vendedor`, el resultado es ✅ **ACEPTAR**. - Alice quiere ver todos los pedidos para ver si la venta cumple con sus expectativas: - El usuario Alice realiza `leer` en el recurso Pedidos (`https://api.bookstore.io/orders`). - Como a Alice se le ha asignado el permiso de `leer` los Pedidos según su rol de `vendedor`, el resultado es ✅ **ACEPTAR**. - Bob quiere navegar por la lista de libros para ver si hay algún libro que quiera comprar. - El usuario Bob realiza `leer` en el recurso Libros (`https://api.bookstore.io/books`). - Como a Bob se le ha asignado el permiso de `leer` los Libros según su rol de `cliente`, el resultado es ✅ **ACEPTAR**. - Bob quiere ver el pedido de Carol. - Como es el pedido de otra persona, el permiso `leer:yo` de `Pedidos` no funciona aquí. - El usuario Bob realiza `leer` en el recurso Pedidos (`https://api.bookstore.io/order`). - Como Bob no tiene permiso de `leer` los Pedidos, el resultado es ❌ **DENEGAR**. ### Otros niveles RBAC Hay cuatro niveles en el modelo RBAC de NIST: - RBAC Plano - RBAC Jerárquico - RBAC Restringido - RBAC Simétrico Ve el [documento](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) para detalles si estás interesado. Logto ahora tiene la implementación del Nivel 1 y avanzará a niveles superiores basado en la retroalimentación de la comunidad. ¡No dudes en hacernos saber si un nivel superior se ajusta a tus necesidades! ## En la práctica Además de la teoría, aún tenemos trabajos técnicos pesados para completar con el fin de hacer que el modelo funcione como se espera: - Desarrollo de servidor de autenticación y cliente - Diseño de base de datos para RBAC - Validación a través de diferentes servicios - Cumplimiento de seguridad y estándares abiertos - Gestión de roles, permisos, recursos y asignación No entres en pánico. Hemos tomado esto en cuenta y añadimos soporte fuera de la caja para cubrir todo lo anterior. Consulta la [🔐 Receta RBAC](https://docs.logto.io/docs/recipes/rbac/) para aprender cómo usar RBAC en Logto. ## Notas finales RBAC es un poderoso modelo de gestión de acceso para la mayoría de los casos, pero no hay una solución única para todos. Todavía tenemos algunas preguntas: - ¿Necesito niveles altos de RBAC? - ¿Cómo se compara RBAC con otros modelos de autorización? - ¿Cómo definir el modelo de autorización entre diferentes Organizaciones? 🔥 Mantente sintonizado. ¡Nos vemos en CIAM 103!