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?
Description
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: * IT:AD:Unity:HowTo:Interception