2009-02-24 13 views
7

Tengo una capa de lógica de negocios (el "repositorio") que se expone como un conjunto de interfaces .NET respaldadas por implementaciones concretas intercambiables. Originalmente tenía esta capa empresarial implementar autenticación y autorización (authn/authz), lo que significaba que tenía interfaces como IUserIdentity e IUserRole, y todos los métodos que accedían a datos confidenciales tomaban IUserIdentity y realizaban la autorización antes de permitir la acción.¿Debería la capa de lógica de negocios implementar la autorización y autenticación?

La capa de negocio ha sido muy independiente antes de este punto ... pero ahora, cuando intento integrarme en un sitio web ASP.NET, me doy cuenta de que ASP.NET tiene una autenticación/autorización enriquecida sistema integrado en él a través de las API de Membresía y Función.

Entonces, la pregunta es, ¿debería eliminar todos los authn/authz de la capa de lógica de negocios y confiar en la interfaz web para hacer esto? Esto simplificaría mucho las cosas, pero no sé si luego me arrepentiré de haberlo movido.

La alternativa es mantener el authn/authz en mi lógica comercial pero integrarlo con ASP.NET a través de proveedores de Membresía/Función personalizados. Sin embargo, esto parece bastante engorroso ... Todavía necesito investigar el costo de hacer esto.

¿Qué harías (o has hecho) y por qué?

Respuesta

5

Creo que la seguridad es una preocupación transversal que pertenece en aspectos. No sé si .NET tiene aspectos, a menos que use Spring.NET.

+0

En realidad (lo siento, debería haber mencionado esto) Estoy usando ASP.NET MVC, que implementa el concepto de aspecto para la seguridad a través del atributo Autorizar. – DSO

+0

atributos en .NET son como anotaciones en Java EE, si no recuerdo mal. ¿Hay algo así como el lenguaje de expresión AspectJ para aplicar un aspecto a una gama de métodos, clases, paquetes? – duffymo

1

Guárdelo. Autenticación de formularios en ASP.NET es muy fácil de personalizar y su capa de lógica de negocios permanece agnóstica.

Considera la posibilidad de mantenerte alejado de this approach y en su lugar prueba Forms Authentication. Básicamente, puede llamar a sus métodos establecidos desde un evento Authenticate de un control de inicio de sesión.

0

¿Está planeando utilizar varios front-ends (asp.net, winforms, mobile?) O exponer la capa de negocios a través de servicios (web)? Entonces probablemente deberías implementar la autenticación en la parte superior de la capa de negocios.

Cuando lo único que desea es otorgar/deney access, puede usar la seguridad integrada en IIS y nunca utilizar un código personalizado para ello.

También puede consultar el proveedor de membresía asp.net.

1

Te sugiero que mantengas la lógica existente, y escribas un miembro personalizado/proveedor de roles alrededor de tus clases de seguridad existentes si quieres usar el mismo directamente usando asp.net. Esto debería ser más fácil de lo que piensas.

http://www.codeproject.com/KB/aspnet/customaspnetproviders.aspx

Como ya dispone de clases para el manejo de permisos de seguridad, esto sólo significa envolver la lógica existente.

Esto también le ayudará a utilizar su lógica de seguridad más tarde, digamos, cuando se crea un cliente Winform que consume su lógica de negocio, o cuando se expone la lógica de negocio como servicios web

0

Creo que el papel La seguridad basada debe estar en Business Layer, que es donde lo ubica CSLA.

Cuestiones relacionadas