Should business logic layer implement authorization & authentication?

Question

I have a business logic layer (the "repository") which is exposed as a set of .NET interfaces backed by swappable concrete implementations.

Originally I had this business layer implement authentication and authorization (authn/authz), meaning I had interfaces such as IUserIdentity and IUserRole, and all methods that accessed sensitive data took an IUserIdentity and performed authorization before allowing the action.

The business layer has been very front-end agnostic up to this point... but now when I am trying to integrate into an ASP.NET web site, I realized that ASP.NET itself has a rich authentication/authorization system built into it via the Membership and Role APIs.

So the question is, should I remove all the authn/authz from the business logic layer and rely on the web front end to do this? This would simplify things alot but I don't know whether I will later regret moving it out.

The alternative is to keep the authn/authz in my business logic but integrate it with ASP.NET via custom Membership/Role providers. However this seems real cumbersome... I still need to investigate the cost of doing this.

What would you do (or have done) and why?

Answer 1

I think security is a cross-cutting concern that belongs in aspects. I don't know if .NET has aspects, unless you use Spring.NET.