Deja de pelear con permisos complejos: un respiro para tu código

Resumen

Este artículo presenta Amazon Verified Permissions (AVP) como una solución práctica para gestionar la autorización compleja en aplicaciones, con un recorrido paso a paso usando el ejemplo PetStore de AWS.

El problema

¿Alguna vez te has topado con una complejidad enorme al intentar gestionar todos los roles, usuarios y actores de autorización de tu propio producto SaaS? ¿Te suena el dolor de los cambios en los requerimientos del negocio, tratando de aplicar los mejores principios de seguridad mientras haces malabares con code reviews y pruebas a/b relacionadas con los cambios que intentas implementar? Y sí, tu SaaS corre en la nube de AWS.

¡Creo que es hora de respirar hondo y ver el panorama completo! Piensa en tu solución, y vuélvela a pensar, ¡porque quizá pueda mostrarte una relativamente simple! ¡Una que te ayude a manejar la complejidad y a dedicar tus recursos y esfuerzos a lo que de verdad importa: tu negocio y sus necesidades!

Esa solución es Amazon Verified Permissions.

Cómo sueles manejar la autorización en tu aplicación web

Analicemos el sistema de autorización de una aplicación web. La necesidad de un sistema así surge con la evolución de la aplicación. Puedes planearlo con anticipación (lo cual es mejor, como parte del diseño de tu sistema), pero de todos modos enfrentarás cambios a medida que evolucionan los requerimientos del negocio. Tendrás que modificar distintas partes de tu sistema después de haberlo desplegado a producción.

¿Por qué necesitamos un sistema así? Por muchas razones:

• Quieres permitir que ciertos roles vean ciertas partes de tu aplicación
• Necesitas restringir ciertas acciones a roles o usuarios específicos de tu aplicación
• Necesitas reforzar los controles de seguridad y evitar accesos no autorizados
• Tu lógica de permisos termina regada por todo el código, y el mantenimiento se vuelve una pesadilla

Tu sistema de permisos típico: una maraña

La mayoría de los sistemas de autorización hoy se ven más o menos así: bloques de if/else dispersos por todo tu código:

// The typical nightmare in your Lambda or Node.js service:
boolean userAuthorizedForOrder(Order order, User user) {
    if (user.storeId == order.storeId) {
        if (user.roles.contains("store-owner")) {
            return true;  // store owners can access their own store's orders
        } else if (user.roles.contains("customer")) {
            if (user.id == order.customerId) {
                return true;  // customers can only see their own orders
            }
        }
    }
    return false;
}

¿Y después? Agregas otro rol. Luego otro. Luego un caso especial para gerentes regionales. Luego una regla sobre quién puede cancelar pedidos después de 24 horas. Luego un nuevo requerimiento de negocio sobre el acceso los fines de semana. De repente te estás ahogando en condiciones anidadas, tus code reviews son brutales, cada cambio en los requerimientos del negocio se convierte en un despliegue, y la mitad de tu equipo discute casos límite en lugar de construir funcionalidades.

Los verdaderos puntos de dolor

Explosión de roles: Tus 2 roles se convierten en 5, luego en 10, y de pronto tienes un gerente-regional-con-permisos-de-empleado-de-tienda-pero-solo-los-fines-de-semana, y nadie puede llevar la cuenta de quién debería tener qué.

La pesadilla de los code reviews: Cada cambio de permisos requiere cambios de código. Los devs pasan horas debatiendo la lógica de las políticas en los PRs en lugar de lanzar funcionalidades.

Probar la autorización: ¿Cómo se prueban siquiera todas las combinaciones? Matriz de usuarios × roles × recursos × acciones = caos. Se te escapan casos límite y las cosas se rompen en producción.

Trazabilidad de auditoría: Buena suerte explicándole a compliance por qué tal usuario pudo acceder a tal pedido. Está enterrado en el historial de git, repartido en 5 archivos distintos.

Cero flexibilidad: ¿Quieres cambiar permisos un viernes? Mala suerte: eso es un despliegue. ¿Quieres revertir una política rápido? A desplegar otra vez.

Cómo puedes gestionarla con Amazon Verified Permissions

¿Y si tuvieras la oportunidad de simplificar esa carga? ¿Y si te dijera que ya existe un servicio que puede hacer por ti la mayor parte del trabajo de los permisos de tu aplicación web?

En lugar de incrustar la autorización en tu código, ¿qué tal si la separas por completo? ¿Qué tal si los permisos fueran declarativos, versionados, centralizados, y pudieras cambiarlos sin volver a desplegar tu aplicación?

Esa es la promesa de Amazon Verified Permissions (AVP).

La arquitectura

Así funciona (a grandes rasgos):

1. El usuario se autentica vía AWS Cognito (o cualquier IdP)
2. Tu API recibe la solicitud con un token JWT
3. El Lambda Authorizer intercepta la solicitud
4. La Lambda construye una consulta de autorización con: principal (quién), action (qué está haciendo), resource (sobre qué lo hace), context (atributos adicionales)
5. La Lambda llama a AVP con esa consulta
6. AVP evalúa las políticas de Cedar (un lenguaje de políticas diseñado para autorización)
7. AVP devuelve ALLOW o DENY
8. API Gateway aplica la decisión: la solicitud continúa o recibe un 403

La clave está aquí: Toda la lógica de permisos vive en políticas de Cedar dentro de AVP. Tu código solo pregunta "¿está autorizado?" y confía en la respuesta.

El ejemplo real: PetStore

Usé el repositorio PetStore de AWS como aplicación de ejemplo, incluyendo la mayoría de las funcionalidades descritas, pero con algunos ajustes, ya que el esquema incluido no funcionaba — probablemente por actualizaciones que AWS le hizo al servicio. Recuerda que es un servicio relativamente nuevo y asumo que en muchas áreas sigue en desarrollo.

Simplemente sigue los pasos indicados y empieza por desplegar la aplicación de Amplify. Es posible que te pida identificarte con tu cuenta de GitHub para clonar el repo y desplegarlo en tu ecosistema de AWS. Una vez desplegada, mirando el diagrama de arquitectura de arriba, podemos identificar los componentes y cómo se comunican entre sí.

La configuración: el paso a paso

Paso 1: usuarios y grupos en Cognito

Como proveedor de identidad usamos AWS Cognito. Después del despliegue, ve al dashboard de Amazon Cognito y deberías encontrar el User pool que empieza con "petstoresample"; ese es tu pool y ahí es donde debes crear los usuarios y grupos para esta aplicación.

Crea tres usuarios:

Necesitamos crear tres usuarios para esta PoC. Uno debe llamarse explícitamente "abhi", porque está hardcodeado dentro de la función Lambda. Los otros dos son más flexibles — yo los llamé "owner" y "visitor". Al crearlos:

• No envíes verificaciones por correo
• Márcalos como "email address verified"
• Usa contraseñas simples (no querrás restablecerlas después de la configuración)

Al terminar deberías tener algo así:

Agrega atributos personalizados al usuario owner:

No olvides actualizar al usuario "owner" con el atributo personalizado employmentStoreCode. Se usará más adelante como parte de las políticas en Amazon Verified Permissions. Solo haz clic en "Edit" y actualiza para que los atributos de tu usuario se vean así:

Crea los grupos y asigna los usuarios:

Necesitas crear 2 grupos y agregar los usuarios a esos grupos. Estos nombres de grupo ("Store-Owner-Role" y "Customer") forman parte de los tokens emitidos por Cognito y se usarán para el control de acceso basado en roles (RBAC).

El usuario "abhi" debe agregarse al grupo "Customer" junto con el otro usuario, "visitor":

Y obviamente el "owner", con la etiqueta adicional que agregamos, irá al grupo "Store-Owner-Role":

Paso 2: configuración de Amazon Verified Permissions

Con esta parte lista, lo siguiente es revisar y configurar Amazon Verified Permissions. En esta parte también vamos a revisar el Lambda Authorizer y el API Gateway — se desplegaron con el mismo despliegue de Amplify, como parte de la aplicación.

Simplemente busca Amazon Verified Permissions en el buscador y creemos primero un nuevo Policy store. En el repositorio recomiendan empezar por el esquema, pero la interfaz cambió: primero tienes que crear el Policy store. Puedes poner lo que quieras, ya que al final usaremos el esquema que te comparto. Así que puedes especificar un Empty Policy Store para simplificar las cosas; solo dale el nombre "PetStore".

Paso 3: define tu esquema

Esto es crucial. El esquema le dice a AVP qué principals, recursos, acciones y relaciones existen en tu aplicación. Usa este esquema:

{
  "MyApplication": {
    "actions": {
      "GetOrder": {
        "appliesTo": {
          "principalTypes": ["User"],
          "resourceTypes": ["Order"]
        }
      },
      "GetStoreInventory": {
        "appliesTo": {
          "principalTypes": ["User"],
          "resourceTypes": ["Application"]
        }
      },
      "ListOrders": {
        "appliesTo": {
          "principalTypes": ["User"],
          "resourceTypes": ["Application"]
        }
      },
      "PlaceOrder": {
        "appliesTo": {
          "principalTypes": ["User"],
          "resourceTypes": ["Application"]
        }
      },
      "SearchPets": {
        "appliesTo": {
          "principalTypes": ["User"],
          "resourceTypes": ["Application"]
        }
      }
    },
    "entityTypes": {
      "Application": {
        "memberOfTypes": [],
        "shape": {
          "attributes": {
            "storeId": {"type": "String"}
          },
          "type": "Record"
        }
      },
      "Order": {
        "memberOfTypes": [],
        "shape": {
          "attributes": {
            "owner": {
              "name": "User",
              "type": "Entity"
            },
            "storeId": {
              "type": "String"
            }
          },
          "type": "Record"
        }
      },
      "Pet": {
        "memberOfTypes": [],
        "shape": {
          "attributes": {
            "owner": {
              "name": "User",
              "type": "Entity"
            },
            "storeId": {
              "type": "String"
            }
          },
          "type": "Record"
        }
      },
      "Group": {
        "memberOfTypes": [],
        "shape": {
          "attributes": {},
          "type": "Record"
        }
      },
      "User": {
        "memberOfTypes": ["Group"],
        "shape": {
          "attributes": {
            "employmentStoreCode": {"type": "String"}
          },
          "type": "Record"
        }
      }
    }
  }
}

El esquema del proyecto original tiene un pequeño problema, así que, en su lugar, copia este en el esquema de tu Policy Store.

Paso 4: crea las políticas de Cedar

Haz clic en el Policy Store y en el panel izquierdo verás el enlace "Policies". Haz clic ahí y luego en "Create Policy > Create static policy". El asistente de creación de políticas usa el esquema que agregamos. Estamos usando políticas permisivas — el alcance debe definirse para el grupo de participantes, el alcance del recurso debe ser el recurso específico donde eliges lo que necesitas, y el tipo de acción debe seleccionarse como un conjunto específico de acciones.

Hay un truco que puedes usar para ejecutar la política totalmente permisiva: selecciona "All principals", "All resources" y "All actions", guarda la política, luego edítala y simplemente pega la política en lenguaje Cedar. Es un atajo, pero necesitas conocer la declaración de tu política.

Estas son las políticas que necesitarías para esta PoC:

Ejemplo de RBAC — Los clientes pueden buscar mascotas y hacer pedidos:

permit(
  principal in MyApplication::Group::"Customer",
  action in [MyApplication::Action::"SearchPets", MyApplication::Action::"PlaceOrder"],
  resource == MyApplication::Application::"main"
);

Ejemplo de ABAC — Los dueños de tienda solo pueden acceder al inventario de su propia tienda:

permit(
  principal in MyApplication::Group::"Store-Owner-Role",
  action == MyApplication::Action::"GetStoreInventory",
  resource == MyApplication::Application::"main"
)
when {
  principal.employmentStoreCode == resource.storeId
};

Ejemplo de ABAC — Los usuarios solo pueden ver sus propios pedidos:

permit(
  principal in MyApplication::Group::"Customer",
  action == MyApplication::Action::"GetOrder",
  resource is MyApplication::Order
)
when {
  principal == resource.owner
};