Resolución de autorización para desarrolladores de software

No implementaríamos nuestro propio software de procesamiento de pagos o de orquestación en la nube. ¿Por qué seguimos construyendo nuestra propia infraestructura de autorización?

He hablado con cientos de equipos de desarrollo y la mayoría de ellos todavía crean autorizaciones a mano, ad-hoc y sin un plan. Eso es natural, nadie ha desarrollado todavía una «Stripe» o «Twilio» para la autorización que resuelva los problemas de los programadores.

Después del procesamiento de pagos (Stripe), las comunicaciones (Twilio) y tantos otros problemas de los programadores que han sido tallados y simplificados por bibliotecas o servicios especializados, creo que la autorización, el mecanismo para controlar quién puede hacer qué en un sistema, ser la siguiente capa de software que se desagregará.

Y en este post te voy a contar por qué.

La gran desagregación

Cuando crea una aplicación, generalmente tiene un problema específico que está tratando de resolver. Es esencial poder evitar pensar en cualquier cosa que no sea fundamental para ese problema. Afortunadamente, podemos buscar una solución existente para cualquier cosa en la que no queramos pensar en ese momento.

Las dependencias tienen cierto costo de integración, por supuesto, pero bibliotecas o servicios realmente buenos (Stripe es un gran ejemplo, o PostgreSQL). Permítanos agregarlos sin casi ningún esfuerzo. Han separado con éxito su área de interés del código de usuario.

Esto también se aplica a los frameworks y a algunos lenguajes. Cuando trabajan, cuando realmente solucionan los problemas, se siente mágico.

Durante los últimos 15 años, muchas empresas han comenzado a producir esa experiencia.

Las empresas que hacen esto bien eligen dominios con los que todo el mundo necesita lidiar, pero que pocas personas quieren pensar en sí mismas. AWS hizo esto con infraestructura, Twilio con telefonía y Stripe con pagos. Esto solo funciona cuando la experiencia es excelente, por supuesto, que es como Stripe ganó a PayPal. Como dijo un desarrollador anónimo, «Stripe no apesta».

¿Por qué la autorización es tan difícil?

La autenticación es el mecanismo para verificar quién es usted, como una pantalla de inicio de sesión. Es la puerta de entrada a su aplicación. Proveedores como Okta / Auth0 y Amazon Cognito tienen API para la autenticación. La autorización es el mecanismo para verificar lo que tiene permitido hacer, como qué páginas puede ver, qué botones puede hacer clic y qué datos puede tocar.

Es común piratear una solución rápida y sucia para que se inicie la autorización. Por lo general, se parecen a algunas ifdeclaraciones y roles en una base de datos. Eso puede durar un poco hasta que necesite agregar más funciones de autorización, como jerarquías de roles, objetos anidados y relaciones. Cualquier entidad que no se asigne a una lista simple de roles agrega complejidad, y es difícil escribir ese código sin un plan.

O quizás desee permitir que los clientes definan permisos personalizados. O es posible que desee pasar a varios inquilinos o pasar a microservicios. Puede haber una serie de requisitos que no anticipó cuando, comprensiblemente (y a menudo correctamente), comenzó con algunas declaraciones básicas . Cuando llegue ese momento, su equipo inevitablemente hará una gran refactorización (piense en seis a 18 meses) en un dominio que no es fundamental para su negocio. Buenos tiempos.

No lanzaría su propio software de procesamiento de pagos o de orquestación en la nube. Entonces, ¿por qué la mayoría de las empresas siguen construyendo su propia infraestructura de autorización?

La respuesta es que casi todas las autorizaciones son personalizadas, específicas para cada aplicación y, por lo tanto, están estrechamente relacionadas con el código y sus datos subyacentes. Tradicionalmente, ha parecido imposible encontrar una solución genérica.

Para tener una idea de por qué esto es difícil, imagine una aplicación como Google Docs. Tiene documentos que le pertenecen. Puede ver, editar, comentar y eliminar estos documentos. Tienes documentos e incluso carpetas que alguien ha compartido contigo. Tal vez puedas editarlos o simplemente comentarlos. Es posible que haya otros documentos para los que solo tenga acceso de visualización. Entiendes la idea.

Lo que controla todo esto es la autorización. El sistema controla el acceso a archivos y carpetas, organizaciones, equipos, arriba y abajo, en distintos niveles, y le impide ver documentos que no debería. Hay dos aspectos clave de la autorización:

La lógica es específica de la aplicación en sí. La forma en que crearía la autorización para Google Docs es diferente de cómo crearía la autorización para algo como Salesforce o Expensify.
La autorización controla el uso de los datos cotidianos de la aplicación, por ejemplo, quién es el propietario de un archivo, por lo que necesitará acceso completo a esos datos. Esto significa que el sistema de autorización necesita acceder a los datos de su aplicación, que estarán en una forma diferente para cada aplicación.

Cada empresa pasa por un proceso de diseño personalizado para escribir código personalizado para resolver sus problemas de autorización. Miles de empresas, solucionando miles de problemas de autorización, todos los días.

Cómo facilitar la autorización

Por lo tanto, si va a crear una API o una biblioteca para su autorización, deberá abordar los dos requisitos mencionados anteriormente, además de facilitar la vida a los desarrolladores. Necesitaría:

Sea personalizable para la aplicación.
Tener acceso directo a los datos de la aplicación.
Sea lo suficientemente genérico como para ahorrar tiempo y esfuerzo, en comparación con los desarrolladores que escriben el código ellos mismos.

Estos son algunos de los principios básicos sobre los que construimos Oso , un marco de autorización de código abierto que incluye baterías. Oso le brinda un modelo mental y un sistema de autorización, un conjunto de API construidas sobre un lenguaje de política declarativa llamado Polar, para definir quién puede hacer qué en su aplicación. Puede expresar conceptos comunes como «los usuarios pueden ver sus propios datos», controles de acceso basados en roles, organizaciones y equipos, y jerarquías y relaciones. Oso le permite descargar el pensamiento de cómo diseñar la autorización y crear funciones rápidamente, mientras mantiene la flexibilidad para ampliar y personalizar como mejor le parezca.

Para diseñar la autorización de manera eficaz con cualquier sistema, querrá estar familiarizado con los diseños y patrones de sistemas de autorización comunes. En este momento, la autorización es un tema bastante oscuro del que es difícil aprender. Google «Diseño de esquema RDBMS» y obtendrá toneladas de resultados útiles. Pero busque «diseño de autorización», y los resultados serán una mezcolanza de publicaciones medianas aleatorias, páginas de proveedores fuertemente SEO y algunos artículos del NIST. Incluso es difícil encontrar información sobre cómo construir un modelo de datos sensible para algo como el control de acceso basado en roles (RBAC).