2011-07-09 14 views
10

Sea /users/{id} una url de recursos en el servicio RESTful.Autorización de nivel de recursos en el servicio RESTful

La autenticación básica está habilitada y solo los usuarios autenticados pueden acceder a la url.

Ejemplo Escenario:

User_1 & User_2 son usuarios con userId autenticado 1 & 2. Desde ambos están autenticados, ambos están teniendo acceso a,

  • /users/1
  • /users/2

Pero la expectativa es User_1 debe tener acceso a /users/1 y no a /users/2 u otro ID de usuario.

Pregunta: ¿Cómo hacer la autorización de nivel de recursos en los servicios RESTful?

Nota: Estoy implementando RESTful usando Jax-RS (con implementación de Apache CXF), útil si se puede explicar con Jax-RS.

-Barath

Editar:

Como se mencionó Donal, yo no busco a la autorización basada en papel en lugar de recursos autorización nivel.

Para dar un ejemplo, supongamos que/users/{id}/photos/{photoId} sea otra url de recursos. Usuario_1 debe tener acceso a las fotos que le pertenecen solo a él. Si photoId de 2 perteneciente a user_2, deberíamos dar http_404 código de error para user_1 cuando se solicita una solicitud/users/1/photos/2. [Dado que User_1 también es usuario autenticado puede invocar/users// photos/2, por lo que hay que identificar el ID de usuario en función de los parámetros de autenticación que a través de URL de recursos]

la única solución que se me ocurre es decir, incluir el ID único que determina la autorización en cada consulta como,

en lugar de SELECT * FROM PHOTO_TBL WHERE PHOTO_ID=2;

uso SELECT * FROM PHOTO_TBL, USER_TBL WHERE PHOTO_ID=2 AND USER_ID=1 AND USER_ID=PHOTO_ID;

con estos recursos están entregando datos que pertenecen a un usuario específico. [Debe haber un mecanismo para evitar la modificación de la identificación única en el lado del cliente que se utiliza para decidir sobre la autorización (ID de usuario en este caso), ya que todas las peticiones son solicitud STATELESS]

Advertencia: Todos y cada consulta debe ser lo suficientemente inteligente como para entender las preocupaciones de seguridad e incluir una unión adicional. Este es un mal diseño para atar la lógica de seguridad a cada función comercial.

Todavía tengo que analizar la seguridad de Spring y cómo se puede utilizar en este caso de uso.

+0

Como usted nota en la etiqueta, este es un problema de autorización anterior a la autenticación. Esto puede implementarse en la aplicación o como un proxy intermediario que compara la ID de usuario en la URL y en los encabezados de autenticación. – Szocske

+0

@Szocske: Aquí es donde vale la pena ponerlo en la aplicación. Pero puede usar Spring AOP (y Spring Security, naturalmente) para hacerlo más fácil. La única parte un poco complicada es darse cuenta de que esto realmente no es un control de acceso basado en roles, y que el soporte RBAC de SpringSec no es relevante. (Por desgracia, ese es el mejor material tutorial en ...) –

+0

OK, ahora veo la edición de las ID de las imágenes que necesitan unirse a la tabla de usuarios de todos modos. En este caso, sin embargo, hay poca necesidad de la ID de usuario en la URL de todos modos :-) – Szocske

Respuesta

3

recomendaría no tener la identificación del usuario en la URL (como si estuviera siendo 'limitado' por una cabecera de autenticación básica, entonces puede que también acaba de tenerlo 'especifica' por la cabecera de autenticación básica).Esto reducirá el riesgo de introducir una directa vulnerabilidad de objeto de referencia - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References)

En este caso, usted podría tener una de las siguientes direcciones:

/users/CURRENT 
/me 

Como las fotos es un recurso secundario a continuación, usted podría crear el fotos con un "número de secuencia" dentro del usuario. En una base de datos sql, esto significaría tener una "clave compuesta" en las columnas de usuario y de foto.

/users/CURRENT/photo/{user_photo_seq} 
/me/photo/{user_photo_seq} 

Su SQL sería entonces algo como:

SELECT * FROM PHOTO_TBL WHERE USER_ID=<BasicAuthUsername> AND PHOTO_ID=<path param value>; 

Una buena explicación de "Auth Cabeceras básicas":

http://en.wikipedia.org/wiki/Basic_access_authentication

+0

¿Podría explicar qué es un encabezado de autenticación básica? –

1

JAX-RS specifies sub-resource donde en vez de manejar la solicitud en un método , el procesamiento se delega a otro objeto - sub-recurso.

El uso de recursos secundarios es suficiente para cuidar el recurso raíz y los anidados también estarán protegidos.

En el ejemplo, puede ver UserResource y todos sus sub recursos disponibles solo para usuarios autorizados.

@Path("/user/{userId}") 
public class UserResource { 

    private final String userId; 

    public UserResource(@PathParam("userId") String userId, @Context SecurityContext securityContext) { 
    this.userId = userId; 

    boolean authorized = /* authorization code */; 

    if (!authorized) { throw new WebApplicationException(Status.UNAUTHORIZED); } 
    } 

    @Path("photo") 
    public PhotoResource getPhotoResource() { 
    return new PhotoResource(userId); 
    } 

} 

public class PhotoResource { 

    private final String userId; 

    public PhotoResource(String userId) { 
    this.userId = userId; 
    } 

    @GET 
    public Response listAll() { /* ... */ } 

    @GET 
    @Path("{photoId}") 
    public Response present() { /* ... */ } 

} 
Cuestiones relacionadas