Search code examples
securityarchitecture3-tier

Security in 3-Tier applications: in which layer?


By "security" I mean data access rights, for example:

  • Andrew only has read-only access to clients in France
  • Brian can update clients in France and Germany
  • Charles is an administrator, he has read and update rights for everything

I can see potential arguments for each layer.

  1. Data Access Layer

    The DAL only exposes clients to which the user has access, and passes an appropriate error up to the business layer when the user tries to do something unauthorised.

    This simplifies the upper layers, and can reduce the data traffic for users who only have access to a small fraction of the data.

  2. Business Layer

    Because this is where the business logic resides and only the business layer has the complete knowledge of how the security should be implemented.

  3. UI Layer

    A tangent argument is because the UI layer is the one that deals with authentication. A stronger argument is when the application has non-UI functions: calculating the daily P&L, archiving, etc. These programs don't have a security context and creating a fictitious 'system' user is a maintenance nightmare.

  4. A separate layer?

    Slotted somewhere inside the 3?

I'm looking for a cogent argument which will convince me that layer X is the best for large-scale 3-Tier applications. Please refrain from 'it depends' answers ;-).

Thanks.


Solution

  • I guess this may be a subjective topic. Nevertheless, we follow the principle to never trust any external source (e.g. data crossing a service boundary). Typically, modern applications are a bit different from the old client-server three-tier model, since they are usually service-oriented (I see a web server is also as a service).

    This rules out the delegation of access checks to the client - the client may know about the allowed access and use this information to behave differently (e.g. not offer some functionality or so), but in the end only what the service (server) decides to allow counts.

    On the other hand, the database or DAL is too low, since most checks also depend on some business logic or on external information (such as user roles). So this rules out the data layer; in our environments the data access is a trusted space that does not do any checks. In the end, the DB layer and the application server form a logical unit (one could call it a fortress - as per Roger Sessions Software Fortresses book), where no service boundary exists. If the app layer accesses another service however it has to perfom checks on the received data.

    In summary, you might want to get a copy of Roger Sessions book because it does give some valuable input and food for thought on large-scale applications and how to deal with security and other issues.