Where does User Login Logic Belong? 3-Tier Application

Question

I was wondering where user login logic resides in a typical application. In my current App, it seems that the best place would be the UI layer. So if the business layer is ever ported to a new platform (desktop-WPF to webpage for example) the respective platforms would handle their own security. This also seems to follow inline with responsibility principles. For example, my business layer doesn't care if a user is logged in, it only cares that a component has requested a piece of processed data. Likewise my UI layer definitely cares if a user is logged in because it has to know what controls or actions to make visible.

The problem is, logging a user in requires access to the data layer. which the UI layer obviously doesn't have.

If I put the user login component in a shared "common" project, circular dependencies arise.

Is the best practice really to put the user login logic in the business layer?

I'm just interested in common practice patterns or your reasoning for having it in the UI layer vs the Business layer or vice versa or something I haven't thought of.

Thanks!

Answer 1

Most enterprise level applications I have seen implement some form of Security layer which is usually independent and may contain roles, permissions, and login methods. This is usually the security guard that returns whether or not a user has access to a specified resource. This Security layer will usually also have its own data access layer.

Answer 2

Here is a sample of how I've laid out security for an application.

1. User credentials passed in. The presenter forwards credentials to security layer
2. The security layer maintains its own communication with a DAL. Could be separate from the rest of the B/L.
3. DAL returns data to security which is tokenized or given a security key.
4. Security passes the token or security key back to the presenter/controller for the application
5. Application wraps or includes the token or security key with all transactions.

The B/L here can then validate the token/key with Security before processing any transaction.

My references basically lay out like so: