Over the last few years the software industry has been figuring out better ways of solving security problems. One of the remaining conundrums has been figuring out where to put authorization logic. When you start thinking about this, you often end up in a big gray area: where does the "authorization" end and the "business logic" in your method begin? If there were some obvious distinction between the two, you could easily factor out the authorization logic and perhaps even centralize it.

If the authorization logic is simple, perhaps you have to be a member of some group or have some claim in order to be able to call a method, then it's easy to factor out that type of logic. This is what WCF's ServiceAuthorizationManager is all about, for example.

But it's not always that easy, is it? What if you want the outcome of the method to be slightly different depending on the user's security context? Perhaps you're going to use the value of some claim to customize the output, or limit your actions somewhat depending on that context? I've often argued that it's an oversimplification to say that you can factor out all authorization logic from a method, and it looks like Vittorio agrees with me.