Autorización mediante control de acceso

La autorización es el proceso de conceder acceso a las distintas partes y activos de la aplicación web a los usuarios. Una forma habitual de autorizar a los usuarios es mediante el control de acceso, en el que el administrador del sitio define qué permisos deben otorgarse a usuarios y otras entidades para acceder a qué recursos.

La autorización no debe confundirse con la autenticación, que es el proceso de validar que el usuario es quien dice ser, normalmente proporcionando credenciales de cuenta. Una vez autenticado el usuario, el proceso de autorización aún debe llevarse a cabo en cada petición, para asegurarse de que el usuario tiene acceso al recurso solicitado.

Al acceder a la aplicación vía GraphQL, debemos validar si el usuario tiene acceso a los elementos solicitados del esquema. ¿Debe codificarse la lógica de autorización dentro de la capa GraphQL?

La respuesta es no. Como deja claro la documentación en graphql.org, la lógica de autorización pertenece a la capa de lógica de negocio, y desde allí es accedida por GraphQL. De este modo, la aplicación puede tener una única fuente de verdad para la autorización (es decir, la que ofrece WordPress):

Gato GraphQL respeta este principio, reflejando (y, bajo el motor, delegando en) el mecanismo de autorización proporcionado por WordPress.

​

Políticas de Control de Acceso

Entre las distintas políticas de control de acceso que podemos implementar para nuestra aplicación, las dos más populares son Role-Based Access Control (RBAC) y Attribute-Based Access Control (ABAC).

WordPress, y Gato GraphQL, admiten ambas.

Con Role-Based Access Control concedemos permisos basándonos en roles, y luego asignamos los roles a los usuarios. Por ejemplo, WordPress tiene un rol administrator con acceso a todos los recursos, y los roles editor, author, contributor y subscriber con permisos restringidos en diversos grados, como poder crear y publicar una entrada de blog, sólo crearla, o sólo leerla.

Con Attribute-Based Access Control los permisos se otorgan en función de metadatos que pueden asignarse a distintas entidades, incluidos usuarios, activos y condiciones del entorno (como la hora del día o la IP del visitante). Por ejemplo en WordPress, la capacidad edit_others_posts se utiliza para validar si el usuario puede editar las entradas de otros usuarios.

En términos generales, ABAC es preferible a RBAC porque nos permite configurar permisos con un control granular, y el permiso es inequívoco en su objetivo.

Por ejemplo en WordPress, el rol editor tiene la capacidad edit_others_posts, pero podemos desear permitir que una persona con el rol author edite la entrada de otro autor, sin concederle todo el conjunto de permisos que se otorgan a un editor (como también borrar las entradas de otros autores). Por tanto, conceder la capacidad edit_others_posts y comprobar esta condición es más adecuado que comprobar el rol editor.

​

Definir la visibilidad

Cuando el usuario no posee el permiso para acceder al campo solicitado del esquema de GraphQL, ¿cuál debe ser el error devuelto?

Hay dos posibilidades, en conformidad con la visibilidad deseada para el esquema: pública o privada.

Para el esquema público, el esquema de GraphQL expuesto es el mismo para todos los usuarios, y cada campo describe qué permisos se requieren para acceder a él. Al solicitar un campo inaccesible, el mensaje de error explicará por qué no se concede al usuario el acceso.

Para el esquema privado, el esquema de GraphQL se personaliza para cada usuario, y sólo se expondrán aquellos campos a los que el usuario puede acceder. Al solicitar un campo inaccesible, el mensaje de error indicará que el campo no existe.

​

Control de Acceso mediante la interfaz de usuario

En Gato GraphQL, las reglas de control de acceso se inyectan en el esquema en tiempo de ejecución, como configuración definida por el usuario mediante access control lists. De este modo, la capa de GraphQL reflejará inmediatamente los cambios en la política de control de acceso, sin necesidad de actualizar código alguno ni recompilar el esquema:

El administrador del sitio configura la ACL, seleccionando:

• Los campos a validar
• Una regla a validar, entre:
  • ¿debe el usuario estar autenticado?
  • ¿debe el usuario estar desautenticado?
  • ¿debe el usuario tener cierto rol?
  • ¿debe el usuario tener cierta capacidad?
• La configuración específica de la regla:
  • ¿qué roles?
  • ¿qué capacidades?
• La visibilidad:
  • ¿por defecto (es decir, la misma asignada al esquema)?
  • ¿pública?
  • ¿privada?