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 ZITADEL satisface la necesidad de una autorización tan matizada.

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 fuente abierta , 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.

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 comportamiento 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.

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 warrant.dev , cerbos.dev , etc.

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:

• write_article : Sólo para que escriban periodistas.

• edit_article : Solo para que los editores editen artículos.

• review_articles : Para que periodistas senior y editores intermedios y senior revisen artículos.

• publish_article : 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.

  
  

  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

• Incorporación de usuarios : durante el proceso de incorporación de usuarios, cada usuario obtiene un rol, por ejemplo, journalist o editor . 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 junior , intermediate y senior 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".

• Inicio de sesión de usuario : 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.

• Validación del token: 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.

• Control de acceso detallado: 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.

• Separación de preocupaciones : 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.

  
  

  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

1. Cree la organización Media House, vaya a Proyectos y cree un nuevo proyecto llamado Newsroom.

   
   

   

   
   

2. En el proyecto Newsroom, haga clic en el botón Nuevo para crear una nueva aplicación.

3. Agregue un nombre y seleccione el tipo API .

4. Seleccione Básico como método de autenticación y haga clic en Continuar .

5. Ahora revise su configuración y haga clic en Crear .

6. Ahora verá el ID de cliente de la API y el secreto de cliente . Cópialos y guárdalos. Haga clic en Cerrar .

7. Cuando hace clic en las URL de la izquierda, verá las URL de OIDC relevantes. Anote la URL del emisor , token_endpoint e introspection_endpoint .

2. Crear roles en el proyecto de sala de redacción

1. Además, anote el ID de recurso de su proyecto (vaya al proyecto y copie el ID de recurso)

2. Seleccione la casilla Afirmar roles en la autenticación en el panel del proyecto y haga clic en Guardar .

3. Vaya a Roles (en el menú de la izquierda) y haga clic en Nuevo para agregar nuevos roles.

4. Ingrese los roles de editor y periodista como se muestra a continuación y haga clic en Guardar .

5. Ahora verá los roles creados.

3. Crear usuarios en el proyecto de sala de redacción

1. Vaya a la pestaña Usuarios de su organización como se muestra a continuación y vaya a la pestaña Usuarios del servicio . Crearemos usuarios del servicio en esta demostración. Para agregar un usuario del servicio, haga clic en el botón Nuevo .

   
   

   

   
   

2. A continuación, agregue los detalles del usuario del servicio, seleccione JWT para Tipo de token de acceso y haga clic en Crear .

   
   

   

   
   

3. Haga clic en el botón Acciones en la esquina superior derecha. Seleccione Generar secreto de cliente en el menú desplegable.

   
   

   

   
   

   
   

4. Copie su ID de cliente y su secreto de cliente. Haga clic en Cerrar .

   
   

   

   
   

5. Ahora tiene un usuario del servicio, junto con sus credenciales de cliente.

4. Agregar autorizaciones para los usuarios

1. Ir a Autorizaciones . Haga clic en Nuevo .
   

   

   
   

2. Seleccione el usuario y el proyecto para el cual se debe crear la autorización. Haga clic en Continuar .

   
   

   

   
   

3. Puedes seleccionar un rol aquí. Seleccione el rol de periodista para el usuario actual. Haga clic en Guardar .

   
   

   

   
   

4. Puede ver que la usuaria del servicio Lois Lane ahora tiene el rol de periodista en el proyecto 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.

1. Vaya a Metadatos . Haga clic en Editar .
   

   
   

   

   
   

2. Proporcione experiencia_nivel como clave y senior como valor. Haga clic en el icono de guardar y haga clic en el botón Cerrar .

   
   

   

   
   

3. El usuario ahora tiene los metadatos necesarios asociados con su cuenta.
   

   
   

   

   
   

4. 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 Acciones . Haga clic en Nuevo para crear una nueva acción.

2. En la sección Crear una acció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 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); } }); }); }

3. AssignRoleAndExperienceClaims ahora aparecerá como una acción.

4. A continuación, debemos seleccionar un Tipo de Flujo . Vaya a la sección Flujos a continuación. Seleccione Token de complemento en el menú desplegable.

5. Ahora debes elegir un disparador. Haga clic en Agregar activador . Seleccione la creación de token de acceso previo como tipo de activador y seleccione asignarRoleAndExperienceClaims como acción asociada.

6. 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

• python3 --version y
• 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 .env con los valores que recuperamos de ZITADEL.

 PROJECT_ID="<YOUR PROJECT ID>" ZITADEL_DOMAIN="<YOUR INSTANCE DOMAIN eg https://instance-as23uy.zitadel.cloud>" ZITADEL_TOKEN_URL="<YOUR TOKEN URL eg https://instance-as23uy.zitadel.cloud/oauth/v2/token" CLIENT_ID="<YOUR SERVICE USER'S CLIENT ID FROM THE GENERATED CLIENT CREDENTIALS eg sj_Alice>" CLIENT_SECRET="<YOUR SERVICE USER'S SECRET FROM THE GENERATED CLIENT CREDENTIALS"> ZITADEL_INTROSPECTION_URL="<YOUR INTROSPECTION URL eg https://instance-as23uy.zitadel.cloud/oauth/v2/introspect>" API_CLIENT_ID="<THE CLIENT ID OF YOUR API APPLICATION FOR BASIC AUTH eg 324545668690006737@api>" API_CLIENT_SECRET="<THE CLIENT SECRET OF YOUR API APPLICATION FOR BASIC AUTH>"

Ejecute la aplicación:

La API de Flask (en app.py ) utiliza tokens JWT y reclamos personalizados para un control de acceso detallado. Comprueba el nivel de experiencia de reclamo personalizado para los roles journalist y editor en cada solicitud, y utiliza esta información para decidir si el usuario autenticado puede acceder al punto final solicitado.

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 <token>", 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

1. Asegúrese de haber clonado el repositorio e instalado las dependencias necesarias como se describió anteriormente.

   
   

2. Ejecute el script client_credentials_token_generator.py para generar un token de acceso.

   
   

   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

   
   

3. 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.

   
   

4. Si no inició la API de Flask antes, ejecute la API abriendo otra terminal en el directorio del proyecto y ejecutando:

   python3 app.py

   
   

5. 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 your_access_token en los comandos curl con el token de acceso que obtuvo en el paso 2.

Pruebe la API

Escenario 1: el editor junior intenta editar un artículo (éxito)

El usuario con rol editor y nivel_experiencia junior intenta llamar al punto final edit_article .

• curl -H "Authorization: Bearer <your_access_token>" -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 editor y nivel_experiencia junior intenta llamar al punto final publish_article .

• curl -H "Authorization: Bearer <your_access_token>" -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 journalist y nivel_experiencia senior intenta llamar al punto final write_article .

• curl -H "Authorization: Bearer <your_access_token>" -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 journalist y nivel de experiencia "junior" intenta llamar al punto final review_articles .

• curl -H "Authorization: Bearer <your_access_token>" -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 editor y nivel_experiencia senior intenta acceder al punto final review_articles .

• curl -H "Authorization: Bearer <your_access_token>" -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 journalist y nivel_experiencia intermediate intenta acceder al punto final publish_article .

• curl -H "Authorization: Bearer <your_access_token>" -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.