Home/ Questions/Q 4597822
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T23:18:43+00:00

I am working on a project with very detailed security requirements. I would honestly

  • 0

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

However, all attempts at abstracting security have either failed or created “abstractions” as messy as before. Is it possible for security to be so specific that it becomes part of business rules? In some situations violating security, only masks the data, whereas in other situations will terminate the session, and at others time it will trigger default values to be used instead. The are many requirements that respond to security priveleges.

My fundamental question is: could I be in an exceptional case (i.e. one where incorporating security is sound) or am I not understanding something fundamental about abstracting security?

Edit:

tl;dr (of answers as I understand them): authentication (who are you) is very much a cross cutting concern and should be abstracted, whereas authorization (what can you do) is business logic. Lacking that vocabulary and having only the term “security” (or perhaps failing to appreciate the distinction between the two) lead to my confusion.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Security is split into two parts; authentication and authorization. Authentication is a pretty specific use case. How do you determine that a user is trusted out of a set of untrusted users. I think this is cross cutting; you need to keep unauthenticated users out of your system, or a subset of your system.

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

    In the Csla.Net 4 framework, that’s exactly how authorization is treated; as a specialized business rule. You’re not even limited to “user is in role” or “user has permission.” You can make more complex rules “user can edit this field if workflow step has not past this particular step.”

    • 0