¿Cómo las aplicaciones web de alto rendimiento controlan los permisos para su contenido?

Question

¿Cómo las aplicaciones web de alto rendimiento controlan los permisos para su contenido?

#1 de Jeff Ferland (3 votos)
#2 de Freddy (0 votos)

8

Entonces, creo que entiendo la lógica detrás de los estándares de autorización como OAuth. El token de OAuth contiene información sobre el usuario (nombre, rol, etc.), que puedo usar para proteger mi aplicación .

Es sobre la última parte de la oración anterior que tengo una pregunta. Digamos que tengo una aplicación web con 1000 artículos, ¿cómo verifico si un usuario específico (basado en su token de OAuth) tiene acceso a un artículo determinado o no? Veo varias opciones:

Almaceno todos los ID de los artículos que el usuario puede ver en el token de OAuth (por ejemplo, ID1, ID2, ID3, etc.);
A la inversa, también puedo almacenar qué usuarios pueden acceder al artículo (por ejemplo, los usuarios pueden leer el artículo 1, 1, 2, 3). Esto es como un ACL;
Para cada artículo, almaceno qué roles pueden acceder a ese artículo (por ejemplo, el artículo 1 puede leerse por rol: lector). Esto es como RBAC;
No asegure su contenido en absoluto, como Facebook parece hacer (aunque asegúrelo, pero solo revisan su lista de amigos antes de proporcionarle la url directa al recurso).

Para aclarar: no estoy buscando una respuesta que explique que puede colocar reclamaciones en el token en sí, para que no tenga que pulsar la db para recuperar sus reclamaciones (sin estado). Estoy buscando formas en que el back-end de la aplicación utiliza estas reclamaciones para decidir si se otorga o no el acceso a un determinado elemento de contenido.

La opción 1 parece una mala práctica, ya que los tokens se volverán infinitamente grandes para los grandes proveedores.
Si los proveedores grandes utilizan la opción 2 o 3, tendrán una gran cantidad de visitas a la base de datos (verifique si ese usuario puede acceder a ese artículo), lo que no puede ser bueno para el rendimiento. Este aumento de rendimiento es una de las razones por las que Facebook y Twitters utilizan la autorización sin estado, en lugar de la autorización con estado. Supongo que esta penalización de rendimiento en el nivel de contenido es un bloqueo contra el uso de la opción 2 o 3.
Entonces, ¿es la única opción viable ir con 4?

Una última opción que veo es usar la opción 3, combinada con un gran almacenamiento en caché. Como los permisos de contenido no son tan efímeros como los derechos de usuario, esta es la opción que elegiría. Pero, ¿es así como lo hacen los grandes proveedores (Google, Twitter, Dropbox, etc.)? ¿Y cómo se implementa en la práctica?

Actualizar

Alguien me habló sobre Matriz de permisos de Spring que puede poner en la memoria, pero no estoy seguro de si este sería el camino a seguir ...

oauth authorization permissions

pregunta Michael 15.10.2015 - 14:29

fuente

2 respuestas

0

Algunas sugerencias:

Debería almacenar el token de oauth, que obtiene del usuario que inició sesión, en algún lugar. Con cada solicitud puedes verificar este token. Esto crea una gran cantidad de solicitudes y puede ralentizar su servicio. Lo que puede hacer es implementar su propio token en función de este touth que guardó en una base de datos y, por ejemplo, almacenar este lado del cliente del token en una cookie o ID de sesión.

En el extremo posterior, el token debe validarse en cada solicitud. Como puede haber visto google, airbnb y demás, simplemente cargue un diseño básico y el resto se carga con solicitudes de ajax que hacen que toda la página parezca más rápida. Por lo tanto, en cada solicitud debe agregar su token actual y, por supuesto, validarlo en el lado del servidor.

Con esta idea en mente, puede servir a sitios que requieren un inicio de sesión realmente rápido, ya que son en su mayoría estáticos.

Otra idea en las listas de acceso. También puede agrupar al usuario y diferenciar estos derechos por el grupo en el que se encuentra el usuario real.

EDITAR: Hoy en día apostaría por una API segura y en su mayoría páginas HTML estándar para que la API pueda decidir qué entregar. Esto tiene la ventaja de una respuesta rápida y puede realizar todas las comprobaciones en segundo plano.

respondido por el Freddy 21.10.2015 - 20:51

fuente

Lea otras preguntas en las etiquetas oauth authorization permissions

Cómo protegerse contra la fuerza bruta ¿Se pueden utilizar los redireccionamientos de ICMP para redirigir el tráfico en una LAN?

score 3 · Accepted Answer

Cada artículo tiene un objeto de permisos asociado adjunto. Ese objeto de permisos describe el código a evaluar y cualquier parámetro posible. La mayoría de los contextos están bastante normalizados, como en Facebook, donde el contexto podría ser amigos.

Por lo tanto, el control del espectador evalúa sus reglas adjuntas: si eres un amigo, tiene éxito. Esa es una operación bastante rápida. Puede ir más lejos, adjuntando datos específicos al control (comparto algo con todos mis amigos, excepto con Eve, o con una lista específica). También puede establecer reglas para un visor: un editor puede tener un controlador de privacidad adjunto a su contexto que devuelve verdadero para todas las llamadas.

Hay dos buenos ejemplos en la parte superior de mi cabeza que pueden ver algunos de los trabajos de. El primero son los permisos de Amazon AWS: las políticas se adjuntan tanto a los usuarios como a los objetos y describen las acciones permitidas en AWS. En el caso de AWS, la regla comienza con la denegación implícita. Todas las reglas adjuntas al usuario y al servicio se evalúan, y la lógica booleana es if permitted and not explicitly_denied . Echa un vistazo al simulador de políticas IAM para obtener una vista gráfica de cómo se evalúan las cosas.

La otra vista es servicios PAM para Unix , que le permite escribir cualquier código que desee teniendo en cuenta al usuario y marcando el resultado como required , sufficient , o algunas otras opciones.

Para su caso específico, cada uno puede configurar una evaluación para RBAC, una evaluación para específicos

Por cierto, tanto Facebook como Twitter usan autorización con estado. Al menos en el caso de Facebook con respecto a las imágenes, el acceso real a una imagen almacenada en caché no se verifica para permitir el almacenamiento en caché remoto, sino durante la generación de la página. Es una llamada de base de datos cada vez. Una carga de página típica en Facebook puede generar más de 100,000 llamadas de base de datos. Los almacenes de tipo KV simple, memcache y el fuerte paralelismo realmente ayudan a que funcione.