2011-05-13 8 views
6

Estoy trabajando en un proyecto de Winforms (.NET 4) que se basa libremente en MVVM. Por motivos de seguridad, la aplicación se autentica en Active Directory y luego utiliza la seguridad basada en roles para determinar los permisos de acceso a diferentes partes del programa. La seguridad se implementa con el PrincipalPermissionAttribute en la mayoría de lugares, así:¿Deberían existir problemas de seguridad en el modelo de dominio?

<PrincipalPermissionAttribute(SecurityAction.Demand, Role:="Managers")> _ 
Public Sub Save() Implements IProductsViewModel.Save 
    mUOW.Commit() 
End Sub 

Como seguramente se puede decir de la implementación de la interfaz, esta Sub específica se encuentra en un modelo de vista. PrincipalPermissionAttribute comprueba si el usuario actual (Thread.CurrentPrincipal) tiene el rol de administrador.

Lo que me lleva a mi pregunta: ¿Se deberían hacer comprobaciones de seguridad (como las anteriores) en el Modelo de Dominio?

Tengo dos puntos de vista conflictivos al pensar en mí mismo:

1) Mantenga el modelo de dominio ignorantes de tantas otras preocupaciones como sea posible para reducir la complejidad y la dependencia. (Mantenga la seguridad fuera, tal vez implementado en ViewModel).

2) El modelo de dominio es, en cierto modo, el lugar donde "el dinero se detiene aquí". Si implemento seguridad en el modelo de dominio, entonces sé que incluso si falla la seguridad en otra capa, el modelo de dominio debería atraparla.

Entonces, ¿qué dices, seguridad en el modelo de dominio o no?

Respuesta

1

Personalmente, creo que esta preocupación parece pertenecer a la capa de servicio. Presumiblemente, la aplicación persistirá a través de la capa de servicio en un grado u otro para llegar al dominio, y usted fácilmente podría tener un servicio que no sea de dominio para verificar el rol del usuario antes de la confirmación.

La razón por la que lo haría de esta manera se basa en la teoría de que cuanto más se acerca al núcleo del dominio, más costosa se ha vuelto la pila de llamadas. La prevención del abuso/mal uso del dominio en un nivel superior significa una mejor capacidad de respuesta y cohesión.

Además, suponga que el requisito cambia, mientras que alguien en otra función ahora puede hacer la misma operación. Mantener todo esto en la capa de servicio significa que tampoco está cambiando el código que debería estar girando con menos frecuencia. Al menos en lo que he hecho, lo positivo de esto es que cuanto más cerca del núcleo se obtiene, menos probable es que cambie el código. Esto significa que también reduce el cambio de su cambio a "ondulación" a otras áreas que no pretendía.

En una preocupación más amplia, y nada personal, no me gusta la idea de poner acceso a datos de ningún tipo en el ViewModel. ViewModel pretende ser una representación del modelo, específica de una implementación. Estos objetos deberían ser, idealmente, lo más livianos posible. Si se realiza un cambio en un producto, por ejemplo, el cambio pasaría por el servicio, luego al depósito, donde podría registrarse con la unidad de trabajo, esperando ser comprometido.

+0

Algunos argumentos muy buenos para mantener la seguridad fuera del dominio, gracias. En cuanto al acceso a los datos en ViewModel, entiendo de dónde vienes y estoy de acuerdo. Estoy usando EF 4 y mi UOW realmente es solo un envoltorio alrededor de un ObjectContext. Utilizo un enfoque de "UOW por modelo de vista", p. cuando la Vista solicita un nuevo ViewModel, ViewModel trae consigo un UOW que se creó cuando el repositorio extrajo las entidades. La UOW rastrea automágicamente cualquier cambio realizado por ViewModel. Lo único que el ViewModel puede hacer con el UOW es decirle que se comprometa. –

3

Hay 2 tipos de seguridad.

Uno que es puramente técnico: algo así como "todo el tráfico debe pasar por https" o "solo un servicio específico debe tocar la base de datos" o "solo un proceso específico debe poder tocar el sistema de archivos/registro".

Segundo que está relacionado con el dominio. Algo como "solo el usuario con el rol de Secretario puede acceder al historial de pagos" o "los usuarios no autorizados no deberían poder acceder a material contable".

Primero uno debe estar desacoplado del dominio. El segundo debe vivir dentro del dominio.

+0

Gran respuesta, creo que aquí es donde iba en mi pensamiento original. ¿Cómo se protegen las operaciones de solo lectura que pueden no tener una verdadera representación de dominio como, por ejemplo, informes al seguir esta metodología? ¿Tiene una entidad de "informe", o la protege en algún otro nivel? –

+0

Tendría UserRights CanSeeReports que se usaría para la autorización por proceso que es responsable de mostrarlo. Sería mejor si el Informe supiera cómo representarse a sí mismo; de esa manera, el Informe siempre podría garantizar la autorización. Pero estoy de acuerdo con esta pérdida de aislamiento. –

+0

Cuando dices dominio, ¿te refieres al modelo de dominio, por ejemplo, la clase "Orden", o te refieres a un servicio de seguridad que puede validar si el usuario actual tiene ciertos permisos? Acepto que en ciertos casos el servicio de seguridad no tendrá suficiente información, en cuyo caso la responsabilidad recae en el dominio – Sudarshan

Cuestiones relacionadas