¿Cómo integrar "Usuarios" en mi modelo DDD con la autenticación de usuarios?

Sí - muy buena pregunta. Al igual que @ Andrew Cooper, nuestro equipo también pasó por todo esto.

Nos fuimos con los siguientes enfoques (bien o mal):

Proveedor de Membresía personalizado

Ni yo ni el otro desarrollador somos fans de lo incorporado ASP.NET Proveedor de membresía. Es demasiado hinchado para lo que nuestro sitio se trata (sitio web social simple, impulsado por UGC). Hemos creado uno muy simple que hace lo que nuestra aplicación necesita, y nada más. Mientras que el proveedor de membresía incorporado hace todo lo que podría necesitar, pero lo más probable es que no lo haga.

Ticket de Autenticación de Formularios personalizados/Autenticación

Todo en nuestra aplicación utiliza la inyección de dependencias basada en interfaces (StructureMap). Esto incluye la autenticación de formularios. Hemos creado una interfaz muy delgada:

public interface IAuthenticationService
{
   void SignIn(User user, HttpResponseBase httpResponseBase);
   void SignOut();
}

Esta sencilla interfaz permite una fácil burla/prueba. Con la implementación, creamos formularios personalizados ticket de autenticación que contiene: cosas como el ID de usuario y los roles, que se requieren en cada solicitud HTTP, no cambian con frecuencia y, por lo tanto, no se deben obtener en cada solicitud.

Luego usamos un filtro de acción para descifrar el ticket de autenticación de formularios (incluidos los roles) y pegarlo en el HttpContext.Current.User.Identity (para el cual nuestro objeto Principal también está basado en la interfaz).

Uso de [Authorize] y [AdminOnly]

Todavía podemos hacer uso de la atributos de autorización en MVC. Y también creamos uno para cada rol. [AdminOnly] simplemente comprueba el rol para el usuario actual, y lanza un 401 (prohibido).

Simple, tabla única para el usuario, simple POCO

Toda la información del usuario se almacena en una sola tabla (con la excepción de la información del usuario "opcional", como los intereses del perfil). Esto se asigna a un POCO simple (Entity Framework), que también tiene lógica de dominio incorporada en el objeto.

Repositorio/Servicio de Usuario

Repositorio de usuario simple que es específico del dominio. Cosas como cambiar la contraseña, actualizar el perfil, recuperar usuarios, etc. El repositorio llama a la lógica de dominio en el objeto User que mencioné anteriormente. El servicio es una envoltura delgada en la parte superior del repositorio, que separa los métodos de repositorio único (por ejemplo, Find) en otros más especializados (findById, FindByNickname).

Dominio separado de seguridad

Nuestro "dominio" el Usuario y su información de asociación. Esto incluye nombre, perfil, facebook / integración social, etc.

Cosas como "Login", "Logout" están tratando con authentication y cosas como "User.IsInRole " trata con autorización y por lo tanto no pertenecen en el dominio.

Así que nuestros controladores trabajan tanto con el IAuthenticationService como con el IUserService.

Crear un perfil es un ejemplo perfecto de lógica de dominio, que se mezcla con la lógica de autenticación también.

Así es como se ve nuestro:

[HttpPost]
[ActionName("Signup")]
public ActionResult Signup(SignupViewModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            // Map to Domain Model.
            var user = Mapper.Map<SignupViewModel, Core.Entities.Users.User>(model);

            // Create salt and hash password.           
            user.Password = _authenticationService.SaltAndHashPassword();

            // Signup User.
            _userService.Save(user);

            // Save Changes.
            _unitOfWork.Commit();

            // Forms Authenticate this user.
            _authenticationService.SignIn(user, Response);

            // Redirect to homepage.
            return RedirectToAction("Index", "Home", new { area = "" });
        }
        catch (Exception exception)
        {
            ModelState.AddModelError("SignupError", "Sorry, an error occured during Signup. Please try again later.");
            _loggingService.Error(exception);
        }
    }

    return View(model);
}

Resumen

Lo anterior ha funcionado bien para nosotros. I me encanta tener una tabla de usuario simple, y no esa locura hinchada que es el ASP.NET Proveedor de membresía. Es simple y representa nuestro dominio , no ASP.NET es la representación de la misma.

Dicho esto, como dije, tenemos un sitio web simple. Si estás trabajando en un banco sitio web entonces tendría cuidado de reinventar la rueda.

Mi consejo para usar es crear su dominio/modelo primero, antes de que siquiera piense en la autenticación. (por supuesto, de esto se trata DDD).

Luego calcule sus requisitos de seguridad y elija un proveedor de autenticación (listo para usar o personalizado) apropiadamente.

No deje ASP.NET dicte cómo debe diseñarse su dominio. Esta es la trampa en la que la mayoría de la gente cae (incluyéndome a mí, en un proyecto anterior).

¡Buena suerte!