Can security be a daunting task?

Question

I am working on a project with very detailed security requirements. I would not be honestly surprised if the proposed model was as complex as for any intelligence / security agency. Now I read that incorporating security with business logic is a mixture of problems and therefore a practice that should be avoided.

However, all attempts to abstract security have either failed or created "abstractions" as dirty as before. Is it possible for security to be so specific that it becomes part of business rules? In some situations that violate security, it only disguises the data, while in other situations the session is terminated, and at other times it will start the default values ​​that will be used instead. Many requirements that meet security requirements.

My main question is: can I be in an exceptional case (i.e. the one in which the inclusion of security sounds), or I do not understand something fundamental in relation to abstracting security?

---

Edit:

tl; dr (answers, as I understand them): authentication (who you are) is a very complex problem and should be abstracted, while authorization (what you can do) is business logic. The lack of this vocabulary and the presence of only the term “security” (or perhaps the inability to appreciate the difference between them) lead to my confusion.

Answer 1

Safety is divided into two parts; authentication and authorization. Authentication is a fairly specific use case. How do you determine that a lot of untrusted users trust a user. I think this is cross cutting; you need to leave unauthenticated users outside your system or a subset of your system.

Authorization (whether the user can do something) is a very business rule. It can (and often) is very specific and different from each use case. Who determines what roles they can do? Well, business does. No one else can answer this for you.

Within Csla.Net 4, exactly how authorization is handled; as a specialized business rule. You are not even limited to "user in role" or "user has permission." You can create more complex rules: "the user can edit this field if the workflow step has not passed this specific step."

Answer 2

I suppose an exception would be if your business logic is security services, and then yes. However, I think your problem may be that you are confusing user authorization with authentication.

Of course, authentication should have a set of rules associated with it, but the end result should be: user identification and session creation.

Authorization will be separated from where we define the user's role, and what privileges are laid out by this role.

A typical example is that Authentication returns a User object and stores it in a session. The user has from 1 to many roles. A role can have from 1 to many privileges. The business logic method may be sendEmail. This method queries the User object for a specific privilege, if one exists, does something, if it does not do something else.

EDITOR: Security, in my opinion, should always be a cross-cutting issue when it comes to the user, however, if your business logic includes properties of objects that are not a user, CRUD of these objects or administration of other users, then this falls into meeting your business requirements and thus is the business logic.