simplemembership provider tied to system.web

Question

we would like to use simplemembership provider in our app. However, we feel like validating that a user is in a role should be a part of the business logic. Simplemembership requires a dependency on System.web which we would not like to reference in the business logic.

Is there a way to decouple System.web from simplemembership provider?

Answer 1

I am not sure I agree that validating that a user is in a role should be part of the business logic. I would like to hear more details about this reasoning. But if you are going to put authorization in the business logic here is a method that still decouples the security model from your business model. This article explains how to do it using the new ASP.NET Identity used in MVC 5, but the same concepts will work with SimpleMembership. Dependent upon your reasoning for moving authorization into the business logic, the approach described here may also meet your requirements.

It appears from your comments that you are trying to reuse the authorization logic by placing it in the business logic, therefore not having to rewrite the authorization logic for each type of client that you put it in. But the fact is the logic will be different dependent upon the client. Just take the example of comparing authorization for an MVC View as opposed to a Web API. The MVC framework actually provides two different AuthorizeAttribute for each because you want to behave differently on authorization failure. If authorization fails on a View you want to redirect to the logon page. If authorization fails on a Web API call you want to return an HTTP unauthorized error. Two different behaviors for different types of clients that could access exactly the same business logic.

I think coupling your security logic with the business logic will actually make the business logic less reusable across different implementations. In Microsoft's Business Layer Guidelines they specifically state, "Do not mix authorization code and business processing code in the same components." I would further decouple your security model from the application by using the approach described here. This will allow you to change your security model at run-time instead of having to recompile and redeploy your application. And the security model will change.