Más allá del inicio de sesión: implemente una autorización detallada con ZITADEL

Introducción A medida que avanzamos hacia una mentalidad de confianza cero, se vuelve clara la limitación de las medidas de seguridad generales como el sistema RBAC tradicional. Una parte esencial del cambio hacia la confianza cero que a menudo no se discute es el paso de una seguridad de grano grueso a una seguridad de grano fino. La autorización detallada aborda esto basando el acceso en atributos como roles de usuario, acciones e incluso contexto como tiempo o ubicación, y ese control de acceso detallado es vital para las aplicaciones modernas. Este artículo analiza cómo satisface la necesidad de una autorización tan matizada. ZITADEL Con las funciones de ZITADEL, como roles, metadatos y acciones, los usuarios pueden obtener un control de acceso muy detallado adecuado para una configuración de confianza cero. Además, ZITADEL puede trabajar con servicios de autorización externos. Mecanismos de autorización que ofrece ZITADEL ZITADEL es un , solución de gestión de acceso e identidad (IAM) nativa de la nube escrita en Go. ZITADEL está disponible como solución SaaS y también es de código abierto para quienes buscan opciones de autohospedaje, lo que garantiza flexibilidad. Atiende casos de uso tanto B2C como B2B. fuente abierta Sus objetivos principales incluyen proporcionar funciones llave en mano para autenticación, autorización, inicio de sesión e inicio de sesión único (SSO), al tiempo que permite la personalización a través de interfaces de usuario. Viene con un extenso registro de auditoría para rastrear todos los cambios, permite a los desarrolladores ampliar las funcionalidades con código personalizado (acciones), admite estándares ampliamente reconocidos como OIDC, OAuth, SAML y LDAP, enfatiza la facilidad de operación y escalabilidad, y ofrece API integrales para integración versátil. Control de acceso basado en roles (RBAC) y acceso delegado ZITADEL utiliza RBAC para administrar los permisos de los usuarios, donde los permisos están vinculados a roles y a los usuarios se les asignan estos roles. Esto simplifica la gestión del acceso de los usuarios en función de sus funciones organizativas. Una característica adicional permite delegar roles a otras organizaciones, facilitando el intercambio de permisos con entidades externas. Esto es especialmente valioso para organizaciones interconectadas o jerárquicas. Si bien estas capacidades ofrecen un control de acceso sólido, es posible que no sean suficientes para necesidades de autorización complejas, de ahí la importancia de explorar la autorización detallada en ZITADEL. La función de acciones, metadatos personalizados y reclamos de control de acceso basado en atributos (ABAC) ZITADEL potencia la tradicional RBAC introduciendo su dinámica característica para el control de acceso basado en atributos (ABAC). A diferencia de RBAC, que otorga acceso según los roles de los usuarios, ABAC es más versátil y evalúa los atributos vinculados al usuario, la acción y el recurso durante las solicitudes de acceso. comportamiento Con las acciones de ZITADEL, se pueden crear scripts posteriores a la autenticación para analizar atributos específicos del usuario y bloquear el acceso cuando sea necesario. Las acciones también pueden establecer reclamos personalizados para impulsar el sistema ABAC, habilitando modelos de autorización avanzados que restringen el acceso en función de atributos como la ubicación, la hora o cualquier factor definible. ZITADEL permite a los administradores o desarrolladores autorizados agregar metadatos personalizados a usuarios y organizaciones, ampliando las posibilidades de control de acceso detallado. Admite reclamaciones agregadas mediante la recopilación de datos adicionales de sistemas externos como CRM o herramientas de recursos humanos. ZITADEL también puede administrar recursos únicos, como pedidos de envío o dispositivos IoT, y determinar el acceso en función de atributos como subusuario, roles, reclamos, IP y más. Ampliación de las capacidades existentes de ZITADEL para un control de acceso detallado A pesar de las funciones integrales que incluye ZITADEL, puede haber casos en los que se necesite un enfoque más personalizado o detallado. Actualmente, la forma más eficaz de implementar una autorización detallada en ZITADEL es mediante el uso de una lógica de aplicación personalizada para proyectos más pequeños o para proyectos de mayor escala, aprovechando una herramienta de terceros disponible como , , etc. warrant.dev cerbos.dev Estas herramientas pueden integrarse con ZITADEL, mejorando aún más su capacidad para una autorización matizada y detallada. Un ejemplo práctico Supongamos que hay una aplicación de sala de redacción hipotética en una empresa de medios, que se comunica con una API de back-end. Los periodistas lo utilizan para escribir, mientras que los editores editan y publican estos artículos. Esta API, escrita en Python Flask en este ejemplo, tiene puntos finales específicos y el acceso a estos puntos finales depende del rol del usuario y de su experiencia. Los puntos finales: : Sólo para que escriban periodistas. write_article : Solo para que los editores editen artículos. edit_article : Para que periodistas senior y editores intermedios y senior revisen artículos. review_articles : Para que publiquen periodistas y editores senior de nivel intermedio y senior. Internamente, la API utiliza un JWT emitido por ZITADEL para comprobar quién realiza las solicitudes. Los usuarios deben enviar un JWT válido en el encabezado de su solicitud. Este JWT se obtuvo cuando el usuario inició sesión. publish_article El JWT contiene información sobre el usuario, como su función y experiencia. Esta información, contenida en reclamos personalizados, es clave para este caso de uso. El backend decide si el usuario puede acceder al recurso solicitado en función de esta información. La lógica de la aplicación : durante el proceso de incorporación de usuarios, cada usuario obtiene un rol, por ejemplo, o . Esto es clave ya que establece quién obtiene qué acceso en nuestra configuración. Gestión de experiencia/antigüedad: además de los roles, se realiza un seguimiento de la experiencia de un usuario (como , y en nuestro ejemplo). Si la experiencia de un usuario cambia, ZITADEL la actualiza como metadatos. Si no se menciona ningún nivel de experiencia cuando un usuario se incorpora a ZITADEL, el sistema simplemente asume que es "junior". Incorporación de usuarios journalist editor junior intermediate senior : un usuario primero debe iniciar sesión para acceder a la API. Al iniciar sesión exitosamente, ZITADEL devuelve un token con la información del usuario. Inicio de sesión de usuario cuando una solicitud de un usuario llega a la API, la API valida el token llamando al punto final de introspección del token de ZITADEL. Aunque los JWT se pueden validar localmente utilizando JWKS, optamos por el método de ZITADEL para inspeccionar los tokens para mayor seguridad y comprobaciones instantáneas de los tokens. De esta manera podemos revocar tokens al instante, gestionarlos desde un solo lugar y tener menos problemas de seguridad. Mantiene los controles de inicio de sesión y acceso de nuestra API sólidos y actualizados con el servidor. Validación del token: la aplicación es responsable de autorizar el acceso a los recursos según la función y el nivel de experiencia del usuario. Utiliza una lista de control de acceso predefinida que asigna cada punto final de recurso a los roles de usuario y niveles de experiencia autorizados para acceder a ellos. Esta lista sirve como libro de reglas para otorgar o denegar el acceso a los recursos. Control de acceso detallado: : en el diseño de esta API, se prestó especial atención a garantizar que la lógica empresarial y las reglas de control de acceso estén claramente separadas. Esto es crucial para la mantenibilidad y escalabilidad de la aplicación. Al mantener separadas la lógica empresarial y las reglas de acceso, obtenemos un diseño modular más limpio. Separación de preocupaciones Esto nos permite actualizar acciones comerciales y reglas de acceso sin afectarse entre sí. Esto aumenta la capacidad de mantenimiento del código y hace que sea más fácil de administrar a medida que la aplicación escala. Además, este diseño hace que el sistema sea más seguro ya que las reglas de acceso se abstraen de la lógica empresarial principal, lo que reduce el riesgo de introducir accidentalmente vulnerabilidades de seguridad al modificar la lógica empresarial. Configurar ZITADEL 1. Cree una organización de medios, un proyecto de sala de redacción y una API de artículos Cree la organización Media House, vaya a y cree un nuevo proyecto llamado Newsroom. Proyectos En el proyecto Newsroom, haga clic en el botón para crear una nueva aplicación. Nuevo Agregue un nombre y seleccione el tipo . API Seleccione como método de autenticación y haga clic en . Básico Continuar Ahora revise su configuración y haga clic en . Crear Ahora verá el de la API y el . Cópialos y guárdalos. Haga clic en . ID de cliente secreto de cliente Cerrar Cuando hace clic en de la izquierda, verá las URL de OIDC relevantes. Anote la URL , e . las URL del emisor token_endpoint introspection_endpoint 2. Crear roles en el proyecto de sala de redacción Además, anote el de su proyecto (vaya al proyecto y copie el ID de recurso) ID de recurso Seleccione la casilla en el panel del proyecto y haga clic en . Afirmar roles en la autenticación Guardar Vaya a (en el menú de la izquierda) y haga clic en para agregar nuevos roles. Roles Nuevo Ingrese los roles de y como se muestra a continuación y haga clic en . editor periodista Guardar Ahora verá los roles creados. 3. Crear usuarios en el proyecto de sala de redacción Vaya a la pestaña de su organización como se muestra a continuación y vaya a la pestaña . Crearemos usuarios del servicio en esta demostración. Para agregar un usuario del servicio, haga clic en el botón . Usuarios Usuarios del servicio Nuevo A continuación, agregue los detalles del usuario del servicio, seleccione para y haga clic en . JWT Tipo de token de acceso Crear Haga clic en el botón en la esquina superior derecha. Seleccione en el menú desplegable. Acciones Generar secreto de cliente Copie su ID de cliente y su secreto de cliente. Haga clic en . Cerrar Ahora tiene un usuario del servicio, junto con sus credenciales de cliente. 4. Agregar autorizaciones para los usuarios Ir a . Haga clic en . Autorizaciones Nuevo Seleccione el usuario y el proyecto para el cual se debe crear la autorización. Haga clic en . Continuar Puedes seleccionar un rol aquí. Seleccione el rol de para el usuario actual. Haga clic en . periodista Guardar Puede ver que la usuaria del servicio ahora tiene el rol de en el proyecto . Lois Lane periodista Newsroom 5. Agregar metadatos a los usuarios Ahora, agreguemos metadatos al perfil del usuario para indicar su nivel de antigüedad. Utilice 'nivel_experiencia' como clave y, para su valor, elija entre 'junior', 'intermediate' o 'senior'. Aunque normalmente podemos asumir que estos metadatos se configuran a través de una llamada API realizada por la aplicación de recursos humanos, para simplificar y facilitar la comprensión, configuraremos los metadatos directamente en la consola. Vaya a . Haga clic en . Metadatos Editar Proporcione como clave y como valor. Haga clic en el icono de guardar y haga clic en el botón . experiencia_nivel senior Cerrar El usuario ahora tiene los metadatos necesarios asociados con su cuenta. También puede agregar algunos usuarios más del servicio con diferentes roles y niveles de experiencia (usando metadatos) para probar la demostración siguiendo los pasos anteriores. 6. Cree una acción para capturar roles y metadatos en un reclamo personalizado 1. Haga clic en . Haga clic en para crear una nueva acción. Acciones Nuevo 2. En la sección , asigne a la acción el mismo nombre que el nombre de la función, es decir, asignarRoleAndExperienceClaims. En el campo del script, copie y pegue el siguiente código y luego haga clic en . Crear una acción Agregar function assignRoleAndExperienceClaims(ctx, api) { // Check if grants and metadata exist if (!ctx.v1.user.grants || !ctx.v1.claims['urn:zitadel:iam:user:metadata']) { return; } // Decode experience level from Base64 - metadata is Base64 encoded let experience_encoded = ctx.v1.claims['urn:zitadel:iam:user:metadata'].experience_level; let experience = ''; try { experience = decodeURIComponent(escape(String.fromCharCode.apply(null, experience_encoded.split('').map(function(c) { return '0x' + ('0' + c.charCodeAt(0).toString(16)).slice(-2); })))); } catch (e) { return; // If decoding fails, stop executing the function } // Check if the experience level exists if (!experience) { return; } // Iterate through the user's grants ctx.v1.user.grants.grants.forEach(grant => { // Iterate through the roles of each grant grant.roles.forEach(role => { // Check if the user is a journalist if (role === 'journalist') { // Set custom claims with the user's role and experience level api.v1.claims.setClaim('journalist:experience_level', experience); } // Check if the user is an editor else if (role === 'editor') { // Set custom claims with the user's role and experience level api.v1.claims.setClaim('editor:experience_level', experience); } }); }); } ahora aparecerá como una acción. AssignRoleAndExperienceClaims A continuación, debemos seleccionar un . Vaya a la sección a continuación. Seleccione en el menú desplegable. Tipo de Flujo Flujos Token de complemento Ahora debes elegir un disparador. Haga clic en . Seleccione como tipo de activador y seleccione como acción asociada. Agregar activador la creación de token de acceso previo asignarRoleAndExperienceClaims Y ahora verá el disparador en la lista. Ahora, cuando un usuario solicita un token de acceso, la acción se ejecutará, transformando los roles y metadatos del usuario al formato requerido y agregándolos como un reclamo personalizado al token. Esta reclamación personalizada puede ser utilizada por aplicaciones de terceros para gestionar el acceso detallado de los usuarios. Configurar el proyecto API Clona el proyecto desde GitHub: Ejecute el siguiente comando para clonar el proyecto desde este repositorio de GitHub: git clone https://github.com/zitadel/example-fine-grained-authorization.git Navegue al directorio del proyecto: Después de la clonación, navegue hasta el directorio del proyecto con . cd example-fine-grained-authorization Configure un entorno Python: Asegúrese de tener Python 3 y pip instalados. Puedes comprobar esto ejecutando y python3 --version pip3 --version en tu terminal. Si no tiene Python o pip instalados, deberá instalarlos. A continuación, cree un nuevo entorno virtual para este proyecto ejecutando . python3 -m venv env Active el entorno ejecutando: En Windows: .\env\Scripts\activate En Unix o MacOS: source env/bin/activate Después de ejecutar este comando, su terminal debería indicar que ahora está trabajando dentro del entorno virtual env. Instalar dependencias: Con la terminal en el directorio del proyecto (el que contiene requisitos.txt), ejecute pip3 install -r requirements.txt para instalar las dependencias necesarias. Configurar variables de entorno: El proyecto requiere ciertas variables de entorno. Complete el archivo con los valores que recuperamos de ZITADEL. .env PROJECT_ID=" " ZITADEL_DOMAIN=" " ZITADEL_TOKEN_URL=" " CLIENT_SECRET=" ZITADEL_INTROSPECTION_URL=" " API_CLIENT_ID=" " API_CLIENT_SECRET=" " Ejecute la aplicación: La API de Flask (en ) utiliza tokens JWT y reclamos personalizados para un control de acceso detallado. Comprueba el nivel de experiencia de reclamo personalizado para los roles y en cada solicitud, y utiliza esta información para decidir si el usuario autenticado puede acceder al punto final solicitado. app.py journalist editor aplicación.py from flask import Flask, jsonify from auth import token_required from access_control import authorize_access app = Flask(__name__) # Define the /write_article route. @app.route('/write_article', methods=['POST']) @token_required def write_article(): authorization = authorize_access('write_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article written successfully!"}), 200 # Define the /edit_article route. @app.route('/edit_article', methods=['PUT']) @token_required def edit_article(): authorization = authorize_access('edit_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article edited successfully!"}), 200 # Define the /review_article route. @app.route('/review_articles', methods=['GET']) @token_required def review_article(): authorization = authorize_access('review_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article review accessed successfully!"}), 200 # Define the /publish_article route. @app.route('/publish_article', methods=['POST']) @token_required def publish_article(): authorization = authorize_access('publish_article') if authorization is not True: return authorization # Resource-specific code goes here... return jsonify({"message": "Article published successfully!"}), 200 # Add more endpoints as needed... if __name__ == '__main__': app.run(debug=True) autenticación.py import os import jwt import requests from functools import wraps from flask import request, jsonify, g ZITADEL_INTROSPECTION_URL = os.getenv('ZITADEL_INTROSPECTION_URL') API_CLIENT_ID = os.getenv('API_CLIENT_ID') API_CLIENT_SECRET = os.getenv('API_CLIENT_SECRET') # This function checks the token introspection and populates the flask.g variable with the user's token def token_required(f): @wraps(f) def decorated(*args, **kwargs): token = request.headers.get('Authorization') if not token: abort(401) # Return status code 401 for Unauthorized if there's no token else: token = token.split(' ')[1] # The token is in the format "Bearer ", we want to extract the actual token # Call the introspection endpoint introspection_response = requests.post( ZITADEL_INTROSPECTION_URL, auth=(API_CLIENT_ID, API_CLIENT_SECRET), data={'token': token} ) if not introspection_response.json().get('active', False): return jsonify({"message": "Invalid token"}), 403 # Decode the token and print it for inspection decoded_token = jwt.decode(token, options={"verify_signature": False}) print(f"\n\n***** Decoded Token: {decoded_token} \n\n******") # Add the decoded token to Flask's global context g.token = decoded_token return f(*args, **kwargs) return decorated access_control.py (código de muestra que simula un motor de reglas) import base64 import jwt from flask import g, jsonify # The access_requirements dictionary represents your access control rules. access_requirements = { 'write_article': [{'role': 'journalist', 'experience_level': 'junior'}, {'role': 'journalist', 'experience_level': 'intermediate'}, {'role': 'journalist', 'experience_level': 'senior'}], 'edit_article': [{'role': 'editor', 'experience_level': 'junior'}, {'role': 'editor', 'experience_level': 'intermediate'}, {'role': 'editor', 'experience_level': 'senior'}], 'review_articles': [{'role': 'journalist', 'experience_level': 'senior'}, {'role': 'editor', 'experience_level': 'intermediate'}, {'role': 'editor', 'experience_level': 'senior'}], 'publish_article': [{'role': 'journalist', 'experience_level': 'intermediate'}, {'role': 'journalist', 'experience_level': 'senior'}, {'role': 'editor', 'experience_level': 'senior'}] # Add more endpoints as needed... } # This function checks if the user is authorized to access the given endpoint. def authorize_access(endpoint): # We assume that the token has already been decoded in auth.py decoded_token = g.token # Initialize role and experience_level variables role = None experience_level = None for claim, value in decoded_token.items(): if ':experience_level' in claim: role, _ = claim.split(':') experience_level = base64.b64decode(value).decode('utf-8') break # If there's no role in the token, return an error if not role: return jsonify({"message": "Missing role"}), 403 # If there's a role in the token but no experience level, default the experience level to 'junior' if role and not experience_level: experience_level = 'junior' # If there's no role or experience level in the token, return an error if not role or not experience_level: return jsonify({"message": "Missing role or experience level"}), 403 # Get the requirements for the requested endpoint endpoint_requirements = access_requirements.get(endpoint) # If the endpoint is not in the access control list, return an error if not endpoint_requirements: return jsonify({"message": "Endpoint not found in access control list"}), 403 # Check if the user's role and experience level meet the requirements for the requested endpoint for requirement in endpoint_requirements: required_role = requirement['role'] required_experience_level = requirement['experience_level'] # Experience level hierarchy experience_levels = ['junior', 'intermediate', 'senior'] if role == required_role and experience_levels.index(experience_level) >= experience_levels.index(required_experience_level): return True #return jsonify({"message": "Access denied"}), 403 return jsonify({"message": f"Access denied! You are a {experience_level} {role} and therefore cannot access {endpoint}"}), 403 Ejecute la aplicación Flask ejecutando: python3 app.py Si todo está configurado correctamente, su aplicación Flask ahora debería estar ejecutándose. Este proyecto fue desarrollado y probado con Python 3, así que asegúrese de estar utilizando un intérprete de Python 3. Ejecute y pruebe la API Ejecute la API Asegúrese de haber clonado el repositorio e instalado las dependencias necesarias como se describió anteriormente. Ejecute el script para generar un token de acceso. client_credentials_token_generator.py client_credentials_token_generator.py import os import requests import base64 from dotenv import load_dotenv load_dotenv() ZITADEL_DOMAIN = os.getenv("ZITADEL_DOMAIN") CLIENT_ID = os.getenv("CLIENT_ID") CLIENT_SECRET = os.getenv("CLIENT_SECRET") ZITADEL_TOKEN_URL = os.getenv("ZITADEL_TOKEN_URL") PROJECT_ID = os.getenv("PROJECT_ID") # Encode the client ID and client secret in Base64 client_credentials = f"{CLIENT_ID}:{CLIENT_SECRET}".encode("utf-8") base64_client_credentials = base64.b64encode(client_credentials).decode("utf-8") # Request an OAuth token from ZITADEL headers = { "Content-Type": "application/x-www-form-urlencoded", "Authorization": f"Basic {base64_client_credentials}" } data = { "grant_type": "client_credentials", "scope": f"openid profile email urn:zitadel:iam:org:project:id:{PROJECT_ID}:aud urn:zitadel:iam:org:projects:roles urn:zitadel:iam:user:metadata" } response = requests.post(ZITADEL_TOKEN_URL, headers=headers, data=data) if response.status_code == 200: access_token = response.json()["access_token"] print(f"Response: {response.json()}") print(f"Access token: {access_token}") else: print(f"Error: {response.status_code} - {response.text}") Abra su terminal y navegue hasta el directorio del proyecto, luego ejecute el script usando python3: python3 client_credentials_token_generator.py Si tiene éxito, esto imprimirá un token de acceso a su terminal. Este es el token que utilizará para autenticar sus solicitudes en la API. Si no inició la API de Flask antes, ejecute la API abriendo otra terminal en el directorio del proyecto y ejecutando: python3 app.py El servidor API ahora debería estar ejecutándose y listo para aceptar solicitudes. Ahora, puede utilizar cURL o cualquier otro cliente HTTP (como Postman) para realizar solicitudes a la API. Recuerde reemplazar en los comandos curl con el token de acceso que obtuvo en el paso 2. your_access_token Pruebe la API Escenario 1: el editor junior intenta editar un artículo (éxito) El usuario con rol y nivel_experiencia intenta llamar al punto final . editor junior edit_article curl -H "Authorization: Bearer " -X POST http://localhost:5000/edit_article Resultado esperado: {"message": "Article edited successfully"} Escenario 2: el editor junior intenta publicar un artículo (fracaso) El usuario con rol y nivel_experiencia intenta llamar al punto final . editor junior publish_article curl -H "Authorization: Bearer " -X POST http://localhost:5000/publish_article Resultado esperado: {"message": "Access denied! You are a junior editor and therefore cannot access publish_article"} Escenario 3: Periodista senior intenta escribir un artículo (éxito) Un usuario con rol y nivel_experiencia intenta llamar al punto final . journalist senior write_article curl -H "Authorization: Bearer " -X POST http://localhost:5000/write_article Resultado esperado: {"message": "Article written successfully"} Escenario 4: Periodista joven intenta revisar artículos (fracaso) El usuario con rol y nivel de experiencia "junior" intenta llamar al punto final . journalist review_articles curl -H "Authorization: Bearer " -X POST http://localhost:5000/review_articles Resultado esperado: {"message": "Access denied! You are a junior journalist and therefore cannot access review_articles"} Escenario 5: el editor senior intenta revisar artículos (éxito) El usuario con rol y nivel_experiencia intenta acceder al punto final . editor senior review_articles curl -H "Authorization: Bearer " -X POST http://localhost:5000/review_articles Resultado esperado: {"message": "Article reviewed successfully"} Escenario 6: Periodista intermedio intenta publicar un artículo (éxito) Un usuario con rol y nivel_experiencia intenta acceder al punto final . journalist intermediate publish_article curl -H "Authorization: Bearer " -X POST http://localhost:5000/publish_article Resultado esperado: {"message": "Article published successfully"} Conclusión En este artículo, exploramos la importancia de pasar del RBAC tradicional a un enfoque de autorización más detallado y detallado utilizando ZITADEL. Profundizamos en sus características como acciones dinámicas para ABAC, la capacidad de integrarse con herramientas de terceros y vimos cómo estas capacidades se pueden aplicar prácticamente en un escenario del mundo real. A medida que crecen las demandas de ciberseguridad, plataformas como ZITADEL brindan las soluciones necesarias para desafíos complejos de autorización.