Which layer of an application should keep security logic (permissions, authorization)?

Since the most similar questions are related to ASP MVC I want to know some common right choice strategies.

Lets try to decide, will it go into the business layer or sit on the service layer.

Considering service layer to have a classical remote facade interface it seems to be essential just to land permission checks here as the user object instance is always here (the service session is bound to the user) and ready for .hasPermission(...) calls. But that looks like a business logic leak.

In the different approach with an implementation of security checks in the business layer we pollute domain object interfaces with 'security token' arguments and similar things.

Any suggestions how to overcome this tradeoff or maybe you know the only true solution?

I think the answer to this question is complex and worth a bit of thought early on. Here are some guidelines.

The service layer is a good place for:

• Is a page public or only open to registered users?
• Does this page require a user of a specific role?
• Authentication process including converting tokens to an internal representation of users.
• Network checks such as IP and spam filters.

The business layer is a good place for:

• Does this particular user have access to the requested record? For example, a user should have access to their profile but not someone else's profile.
• Auditing of requests. The business layer is in the best situation to describe the specifics about requests because protocol and other details have been filtered out by this point. You can audit in terms of the business entities that you are setting policy on.

You can play around a bit separating the access decision from the enforcement point. For example, your business logic can have code to determine if a user can access a specific role and present that as a callback to the service layer. Sometimes this will make sense.

Some thoughts to keep in mind:

1. The more you can push security into a framework, the better. You are asking for a bug (and maybe a vulnerability) if you have dozens of service calls where each one needs to perform security checks in the beginning of the code. If you have a framework, use it.
2. Some security is best nearest the network. For example, if you wish to ban IP addresses that are spamming you, that definitely shouldn't be in the business layer. The nearer to the network connection you can get the better.
3. Duplicating security checks is not a problem (unless it's a performance problem). It is often the case that the earlier in the workflow that you can detect a security problem, the better the user experience. That said, you want to protect business operations as close to the implementation as possible to avoid back doors that bypass earlier security checks. This frequently leads to having early checks for the sake of UI but the definitive checks happening late in the business process.

Hope this helps.