DESCANSO, almacenamiento en caché y autorización con múltiples roles de usuario

Question

Tenemos un sistema multi-tenant con múltiples niveles de acceso diferentes, a veces incluso para el mismo usuario ya que cambian de múltiples roles. Estamos comenzando una discusión sobre pasar a una implementación RESTful de cosas. Estoy empezando a mojarme los pies con todo el RESTO.

Entonces, ¿cómo hago para limitar el acceso a los registros correctos cuando acceden a un recurso, particularmente cuando se tiene en cuenta el almacenamiento en caché? Si el usuario A accede a example.com/employees, recibiría una respuesta diferente a la del usuario B; el usuario A incluso puede recibir una respuesta diferente cuando cambia a un rol diferente. Para ayudar a facilitar el almacenamiento en caché, ¿la identificación del rol debe incorporarse de algún modo en el uri? Tal vez algo así como example.com/employees/123 (que infringe las reglas de REST), o como algún tipo de recurso subordinado como example.com/employees/role/123 (que parece una tontería, ya que role/### se va a anexar a URIs por todas partes). Puedo ayudar, pero creo que me estoy perdiendo algo aquí.

editado mencionar multitenencia

Answer 1

Tener las credenciales de usuario actúan como un fuera de banda identificador de recursos (es decir. La presentación de diferentes puntos de vista sobre la misma URL para diferentes roles) apagará desagradable en el camino. Los usuarios y las aplicaciones intercambian URL entre ellos, las cosas se ponen feas cuando eso sucede y la URL simplemente devuelve contenido diferente para credenciales diferentes.

diría que cada función tiene una visión diferente del mundo, por lo tanto, cada función debe tener acceso a un camino diferente para el servicio:

• administradores se conectan a example.com/admin/employees
• usuarios conectarse a example.com/users/employees
• función foo probablemente se conecta a example.com/foo/employees

de esta manera se separa el 'este papel ve el mundo como tal y tal' par t desde la parte 'esta vista del mundo es accesible para role foo'. Un administrador puede conectarse a example.com/users/employees y verificar cómo un usuario común ve el mundo, sin que el administrador tenga que suplantar un alias privilegiado más bajo primero.

También puede usar la parte DNS para el mismo propósito: admin.example.com/employees vs. users.example.com/employees. Esto es especialmente viable para un escenario relacionado, cuando el 'rol' no es un rol de seguridad sino un espacio de nombres multi-tenant (es decir, cada cuenta provisionada por el servicio obtiene su propia 'vista' del servicio).