Question

I’m following the case study in Professional ASP.NET Design Patterns by Scott Millet. In the case study, authentication is handled in the Infrastructure project. It contains implementations like AspFormsAuthentication : IFormsAuthentication, AspMembershipAuthentication : ILocalAuthenticationService.

This works fine, as he is using the built-in membership provider, however, I am NOT, so I would need access to my repositories. In my scenario, wouldn’t it be better to place my ILocalAuthenticationService and AspMembershipAuthentication implementation in the Services project?

I asked this elsewhere, and someone replied:

I would still place the functionality to pull credentials in the Infrastructure layer as this layer aligns vertically to the other horizontal layers and all layers have access to it. Since you are not using the ASP.NET Membership provider and may be using something custom that might just use encrypted credentials, you can still use the Infrastructure layer to wrap the access of those credentials and allow the repository to use them when needed. You could have the Services layer get them and pass them down, but then you have too many layers understanding how the data is going to be retrieved/persisted and what authorization access is required which is not good when attempting to layer and separate concerns.

Great. This makes sense. But I don’t know where to go from here. The code from the case study:

public class AspMembershipAuthentication : ILocalAuthenticationService 
{
    public User Login(string email, string password)
    {
        User user = new User();
        user.IsAuthenticated= false;

        if (Membership.ValidateUser(email, password))
        {
            MembershipUser validatedUser = Membership.GetUser(email);
            user.AuthenticationToken = validatedUser.ProviderUserKey.ToString();
            user.Email = email;
            user.IsAuthenticated = true;
        }

        return user;
    }

    public User RegisterUser(string email, string password)
    {            
        MembershipCreateStatus status;
        User user = new User();
        user.IsAuthenticated = false;

        Membership.CreateUser(email, password, email, 
                              Guid.NewGuid().ToString(), Guid.NewGuid().ToString(),
                              true, out status);

        if (status == MembershipCreateStatus.Success)
        {
            MembershipUser newlyCreatedUser = Membership.GetUser(email);
            user.AuthenticationToken = newlyCreatedUser.ProviderUserKey.ToString();
            user.Email = email;
            user.IsAuthenticated = true;
        }
        else
        {
            switch (status)
            {
                case MembershipCreateStatus.DuplicateEmail:
                    throw new InvalidOperationException(
                           "There is already a user with this email address.");
                case MembershipCreateStatus.DuplicateUserName:
                    throw new InvalidOperationException(
                           "There is already a user with this email address.");
                case MembershipCreateStatus.InvalidEmail:
                    throw new InvalidOperationException(
                           "Your email address is invalid");
                default:
                    throw new InvalidOperationException(
                    "There was a problem creating your account. Please try again.");
            }
        }

        return user;
    }       
}

If I’m not using the membership provider, how do I connect to the database to check if the username and password matches, among other possible checks?

Answer 1

In your infrastructure layer create a class that implements ILocalAuthenticationService and makes the calls you need.

Or, if ILocalAuthenticationService is too ASP.NET-y (with its User return types) you may have to roll your own ILocalAuthenticationService-variant and implement to that.

Then use your IoC container to resolve ILocalAuthenticationService when you need it.