creating an instead of trigger to allow certain users the ability to modify table

Question

I am using SQL Server 2012.

I am trying to write my first trigger.

I have two tables, one is called tblPayroll & another called tblAllowedUsers. Below is a quick view of what they look like,

 tblPayroll                                    tblAllowedUsers

 employee  salary  position  hr person         hr person    host_name
 abc       5       manager   Sally             Sally        EXABC456
 jkl       3       admin     Dave              Dave         EXDFG908
 plk       4       admin     Sally
 ppp       8       admin     Natalie
 lmn       3       manager   Dave

So there are 3 users in my example, Sally, Dave & Natalie. Natalie though is the only person not in the tblAllowedUsers table.

So I want any person in the tblAllowedUsers table to be able to modify, insert or delete any record in the tblPayroll table.

For people (ie Natalie) not in the tblAllowedUsers table though I do not want them to be able to modify, insert or delete records where the employee is a manager in the tblPayroll table.

Is an instead of trigger the correct trigger to use in this situation? I know in my trigger I need to use the HOST_NAME() function to see which user is executing a statement.

I believe the shell of my trigger should be something like below,

create trigger trDefaultPath on MatlabSearchPath
instead of insert, update, delete
as
begin

end

In the middle part I need something like below,

if postion = 'manager'   -- need to check who is running this

    if HOST_NAME() IN tblAllowedUsers
        -- then execute the statement
    else
        -- give an error message
    end
else
  -- then execute the statement
end

Answer 1

If the people are sharing user IDs, there is no trustworthy way to secure the data. Host_name is a client-side parameter that can be easily spoofed even for those with limited technical knowledge. Is your company willing to take the risk that HR/payroll data can be modified and you have no way to tell who really did it? Whoever says yes to that question, make sure you get it in writing or email and keep it forever.

From your responses, it looks like you might have some limit on the number of logins available and you want to have more users than you have logins but users have different roles and permissions. If you really have to share logins, suggest you designate one for READ/WRITE and the other for READ only. That way, you only share the login/password for RW with users who are authorized to RW and the R-only login/password for users who should only be allowed to read. Still a terrible setup from a security perspective but at least now the responsibility of making sure users can only do what they're allowed to is passed back to the users.

Still make sure you have someone respond in email that it's ok to deploy this very poor security model despite your warnings of its risks and recommendations to not do so.