¿Cómo manejar los permisos de ACL basados en campos de grano fino en un servicio RESTful?

7

He intentado diseñar una API RESTful y me han respondido la mayoría de mis preguntas, pero hay un aspecto de los permisos con los que estoy luchando.

Los diferentes roles pueden tener diferentes permisos y diferentes representaciones de un recurso. Por ejemplo, un administrador o el propio usuario pueden ver más campos en su propia representación de usuario frente a otro usuario con menos privilegios. Esto se logra simplemente cambiando la representación en el backend, es decir, decidiendo si incluir esos campos o no.

Además, algunas acciones pueden ser tomadas en un recurso por algunos usuarios y no por otros. Esto se logra al decidir si incluir o no esos elementos de acción como enlaces, por ejemplo: editar y eliminar enlaces. Un usuario que no tenga permisos de edición no tendrá un enlace de edición.

Eso cubre casi todos mis casos de uso de permisos, pero hay uno que aún no he descubierto. Existen algunos escenarios en los que, para una representación dada de un objeto, todos los campos son visibles para dos o más roles, pero solo un subconjunto de esos roles pueden editar ciertos campos.

Un ejemplo:

{
    "person": {
        "id": 1,
        "name": "Bob",
        "age": 25,
        "occupation": "software developer",
        "phone": "555-555-5555",
        "description": "Could use some sunlight.."
    }
}

Teniendo en cuenta 3 usuarios: un administrador, un usuario regular y el propio Bob (también un usuario regular), necesito poder transmitir al frente que:

Los administradores pueden editar todos los campos, el propio Bob puede editar todos los campos, pero un Usuario regular, mientras puede ver todos los campos, solo puede editar el campo de descripción. Ciertamente no quiero que el cliente tenga que tomar la decisión (o incluso, para el caso, tener alguna noción de los roles involucrados) pero necesito una forma para que el backend transmita al cliente qué campos son editables.

No puedo simplemente usar una combinación de representación (los campos devueltos para ver) y los enlaces (ya sea que esté disponible o no un enlace de edición) en este escenario, ya que es más detallado.

¿Alguien ha resuelto esto con elegancia sin agregar la lógica directamente al cliente?

    
pregunta Jason McClellan 30.10.2013 - 08:48

2 respuestas

4

¿Qué le parece agregar permisos específicos como 'enlaces' en su representación de recursos? Básicamente, dejar que el cliente sepa qué atributos están disponibles para la actualización (por usuarios regulares). Tanto Admin como Self son usuarios no habituales a los que se les permite editar todo. En base a su ejemplo de que los usuarios normales solo pueden editar el campo 'descripción', aquí están mis pensamientos:

{
    "person": {
        "id": 1,
        "name": "Bob",
        "age": 25,
        "occupation": "software developer",
        "phone": "555-555-5555",
        "description": "Could use some sunlight.."
        "_links": {
           "href": "/person/1",
           "method": "PUT",
           "attributes": ["description"]
        }
    }
}
    
respondido por el Aziz Shaikh 30.10.2013 - 10:52
1

Otra opción es tener otro recurso (es decir, / permissions / userResource / user / 1) que devolverá los campos que el usuario puede modificar o ver.

{

read: [id,name,age,occupation,etc],

write: [description]

}

Creo que esto es similar a sugerencia anterior .

    
respondido por el user2186497 02.05.2014 - 03:12

Lea otras preguntas en las etiquetas