2012-05-16 18 views
6

Tengo una API que estoy exponiendo a través de REST y estoy deliberando sobre dónde colocar las restricciones de las autoridades.
He leído que hay una mejor práctica para asegurar la capa de servicio, ya que es la que está haciendo el trabajo y no sabes a dónde se va a llamar, pero no estoy seguro de cuál es la mejor práctica con respecto a la capa WS.
Un pensamiento que tengo es que necesito tener un modelo de autorización de grano muy fino en la capa de servicio y un modelo de autorización de grano grueso en la capa de WS para minimizar el rompimiento del principio DRY por un lado, pero aún tener algunos noción de defensa en profundidad.¿Seguridad de resorte que asegura la capa de servicio, la capa de servicio web o ambas?

Ejemplo:

Para el recurso Users hay un UserWS y una UserService. Los administradores pueden crear/actualizar/eliminar usuarios y los usuarios pueden leer sobre otros usuarios.
Suponiendo que UserWS está obligado a %root%/users Definiré un intercept-url para esa url con la autorización ROLE_USER que dice que debe ser un usuario para llegar allí, pero la capa de servicio especificará las autoridades específicas para los métodos pertinentes.

Otras opciones son:

  • Coloque los mismos requisitos de autorización, tanto en el servicio y la WS-
    Pro-Vas a filtrar tan pronto como posibles intrusos (y ahorrar, por ejemplo, la la conversión de los parámetros si está utilizando MVC primavera)
    Con- Duplicación de configuración es un problema de mantenimiento y es propenso a errores tema => seguridad

  • Coloque el authorizati sobre requisitos sólo en la WS
    Pro- filtro tan pronto como sea posible si comming por el LR
    confirma la capa de servicio puede ser utilizado de diferentes contextos

  • Plate los requisitos de autorización sólo en el servicio-
    pro- hay duplicación
    Overhead Con- de permitir "rodeos" solicitud inepto para llegar a la capa de servicio

realmente apreciaría cualquier comentario acerca de las opciones

Respuesta

5

Ittai, El uso del mismo mecanismo de seguridad tanto en WS como en Service layer se considera que se repite a sí mismo, y requiere mantenimiento en estos dos niveles. No tener ningún tipo de seguridad en la capa WS es algo malo, ya que de hecho permite que alguien ingrese a su sistema (incluso si los bloquea más adelante), muchos lo ven como algo malo. En resumen, creo que debería mezclar estos dos: utilice un mecanismo muy tosco en la capa WS y uno muy fuerte en la capa de servicio. Así es como no se repetirá y no tendrá que mantener el código en ambos lugares (ya que no es el MISMO nivel de seguridad); y podrá filtrar a los usuarios de menor tamaño tan pronto como sea posible, pero aún así tener un nivel de seguridad muy alto donde debería ubicarse.

0

Yo diría que ambas tienen tiempo, solo la capa de servicio si no es así.

Siempre es bueno asegurar la presentación y los servicios porque si alguna vez expone sus servicios a otra cosa que no sea la presentación (expone un servicio web, por ejemplo), tendrá su seguridad en su lugar y listo.

Además, si alguien encuentra una forma de evitar su capa de presentación (digamos que tiene niveles y sus servicios se ejecutan en una máquina remota), igual tendrá su seguridad en su lugar.

+0

gracias por su respuesta, pero como he dicho, si solo tengo las MISMAS autoridades en ambos, entonces es una duplicación y es propenso a errores (por lo tanto, responsabilidad de seguridad). Suponiendo que anote la capa de servicio, ¿qué crees que debería colocar en el WS y por qué? Gracias – Ittai

+0

en mi humilde opinión solo necesita tener un solo servicio que tenga la lógica y tenga un delegado de UI para ese servicio y un delegado de WS. De esta manera solo necesita anotar el servicio concreto. En general, si no desea duplicación, debe asegurar el componente que contiene la lógica real. – Simeon

Cuestiones relacionadas