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.

Answer 2

Keep it. Forms Authentication in ASP.NET is very easy to customize and your business logic layer remains front-end agnostic.

Consider staying away from this approach and instead try Forms Authentication. Basically, you can call your established methods from an Authenticate event of a Login control.

Answer 3

Are you planning to use multiple front-ends (asp.net, winforms, mobile?), or exposing the business layer via (web) services? Then you should probably implement authentication on top of the business layer.

When all you want is to grant / deney access, you could use integrated security on IIS, and never wite custom code for it.

You could also look into the asp.net membership provider.

Answer 4

I suggest you keep the existing logic, and write a custom membership/role provider around your existing security classes if you want to use the same directly using asp.net. This should be easier than you think.

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

As you already have classes for managing security permissions, this just means wrapping your existing logic.

This will also help you to use your security logic later, let us say, when you create a Winform client that consumes your business logic, or when you expose your business logic as web services

Answer 5

I believe the Role Based security should be in the Business Layer, which is where CSLA puts it.