IT:AD:Patterns:Security is an Application concern

Summary

MVC provides the AuthorizeAttribute, and IT:AD:WCF provides the PrincipalPermissionAttribute (see: IT:AD:WCF:HowTo:Use the PrincipalPermissionAttribute) that look nice and easy – but should you use them?

I understand the pull of using them…nice and easy.

But IT:AD:Patterns:MS Sells VS (not Good Practices) Strategy

Security is a cross cutting concern that should be relevant no matter what App Host you are using. The security attributes should be in effect whether you are invoking the application logic through an API, through a command line interface, through a automated test rig, through a web interface, or through a custom legacy POX HttpHandler.

Therefore Security should be applied at the Application layer.

Process

That said, it's harder.

The reason the attributes on the MVC and WCF facades are easy to implement is that public requests are being fed through a factory that is instantiating the controller/service classes, once, and can afford to use reflection to find attributes, etc. before invoking the methods/oeprations. It's pretty seamless.

When invoking a App.Application service, there is no factory…unless you use either AOP or Proxies.

That's doable using Unity, and most other IoC systems.

Unity uses: http://msdn.microsoft.com/en-us/library/ff647107.aspx

Proxies with Unity Interception

An elegant way of doing them is with: