Allow users to view specific records based on custom security requirements-CodePudding

I need some advice on how best to implement a security mechanism in a ASP.net core application. The application users are authenticated using AD authentication. Is there a best practice for this type of implementation?

I have a list of project records. Users should only be able to retrieve a list of projects that they have permission to access. I have three user types that have different levels of access as detailed below.

Approvers – assigned to individual projects.
State approvers – Can view state-wide projects.
Global approvers – Can access all projects.

Does anyone have any suggestions on what model and logic to implement to achieve what is required?

CodePudding user response：

Well, I secure pages with information "limited" to logged on users. So if they have membership in a particale role, then only those users can jump/see such pages.

However, in your case, and often?

Well, it not so much the web page the user can use, or be restricted from.

However, when a web page can be restriced based on IIS security and not your code, then that option should be used.

However, often in code, for example, we have indivdul users from a given company, and ONLY some can and are allowed to see all projects. (so some only can see their own projects, but from that company, some have rights to see use all projects.

So, we often have code say like this:

    Dim cmdSQL As New SqlCommand("dbo.GetProjects", GetCon)
    cmdSQL.CommandType = CommandType.StoredProcedure

    cmdSQL.Parameters.Add("@LogonID", SqlDbType.Int).Value = Membership.GetUser.ProviderUserKey
    cmdSQL.Parameters.Add("Email", SqlDbType.NVarChar).Value = Membership.GetUser.Email
    cmdSQL.Parameters.Add("@PortalMaster", SqlDbType.Bit).Value = IIf(Roles.IsUserInRole("PortalMaster"), 1, 0)

so, if the user is a PortalMaster, then they can get and see all projects belonging to that company. (each company that logs into teh site can have 1 or 20 employees that belong to the given company).

So, in above, the query going to pull projects by EmployeeID (their logon), and thus they can only ever see their own projects.

If you are a member of the PortalMaster group, then we pull projects based on ComapnyID.

So, while you might not be using the older secuirty provider like above? Your queries that pull projects simple have to restrict rows returned based on above.

Once those projects are returned (in a nice grid - searching options included), then they can select (click on) a project. that next page does not really care anymore, since you can't get to the project details page until you selected a project.

So, obvious you must have for a given Project who created it. And thus your ability to display their current projects will be restriced based on their logon ID or whtever you using now.

But, for state level users? Then your critera is by their logon id and their state they belong to based on that logon.

And then there is the "admin" role or group - they can search and pull on all projects.

So, while we do restrict web pages by "role" security (based on IIS), that just means that all users can, or cannot hit some web pages based on their role memember ship (and such security does not require code on my part - the IIS secuirty assinged to those web pages can do all that dirty work for you.

However, if you are a legal logon, then you can only ever work on projects that belong to your company. But then it is a question if that user also has the role of "PortalMaster", and if they do, then we pull all projects for display to select from for that given user.

And of course we never use say URL "query parameters", and such internal database company ID, or ContactID (user id) are never exposed, nor possible allow display of information or data that don't belong to the given user.

So, you need to build some sql or some store procedures, and having a few "parameters" for those stored procedures that returns rows of data based on their role membership is quite much how you would approach this. So in above, if the user is a portal master, then the stored procedure simple queries the data based on company they belong to as opposed to their contact id.

Now, this of course asseumes the database schema is setup, and for example, we hvae a company table, a employee table (that has their logon information), and then of course each project created has both a created by, and the company the project belongs to. So, that simple information is enough to provide the 2 levels of security.

We actually don't have a "super user" that can look at and see all projects in the system, but it actually not all that bad of a idea, since for testing, or checking a project that has some problem is a "pain" right now, since we in theory have to create a logon for that company, or get a password.

So, all logons we create belong to a given company. And thus when a user creates a new project, it can only be created under that one company, and of course a project also requires the user that created the project.

So, you simple have to restrict records returned in the page in which they can select a project to work on. IIS security, or in fact SQL server security as a general rule can't do this type of security for you - you the developer have to.