Using security and permissions

One of the main advantages of stored procedures is how they allow us to have more control over the security of the database. We will be working with a hypothetical user in this exercise called John. There is a script in your exercise files for creating the John user. Consider the scenario where we want to give John read only access to a particular table, and maybe not even the entire table. Maybe just one or two columns in the table. You could manually go in and set all these permissions on the table of our each individual column. You could either grant or deny permission.

But it might be a lot of work to do that for a whole bunch of users. So we can hopefully lower our administrative effort by using a different technique to accomplish the same thing. I have on the screen a basic stored procedure. Again, you can find this in your exercise files. This stored procedure is called securityTest. It will form a SELECT statement. I'm going to select two columns from the authors table, fairly simple. When we Execute this, we get the results we expected. Nothing too exciting just yet. We get FirstName and LastName from every row in the table.

Now let's talk about John. So let's go and give John permission to run this stored procedure. We will right-click on it and at the bottom we have Properties, over here we can go to Permissions, we will be setting permissions for John and we'll go into it and allow him to Execute and that's it. I don't want him doing anything other than executing the stored procedure. So I'll Logout and then log back in, as John.

And he can get into the myDatabase. You can see one of the stored procedures. Now remember our database has three stored procedures. John can only see one of them, the one we gave him permission to, and he should be able to execute that stored procedure. And yes, in fact he can, and he gets the exact same results as any other user. John can not see the table. He doesn't see the underlying table. So he has no way of knowing there were other columns in this table. Some of these other columns in the table are in fact storing things like Address and Phone Number, which could be confidential information.

Using this technique, we've completely masked not only the contents of those columns from John, we've also masked even the fact that those columns exist. So we are in a situation like this where we want a stored procedure to allow access to a table where the user does not have permission to that underlying table, in order for it to work, the stored procedure in the table, we need to have the same owner, and in fact, our stored procedure is owned by dbo. And the table is also owned by dbo.

If either of them was owned by someone else this would not work. So let's go ahead and demo that. I'm going to logout as John. Log back in as someone who has the necessary permissions to change this stuff. So our authors table is currently owned by dbo. Let's go ahead and change that. So we're going to use this stored procedure designed for changing ownership. And it's called SP_changeObjectOwner and the thing we want to change, the owner of is dbo.Authors and we will want to change the owner to Martin, and it looks like it worked.

Click Refresh right here, yes. We'll also need to make one change to the stored procedure. The stored procedure is looking for dbo.Authors, which no longer exists. So we'll change that to Martin.Authors. Then now, I'd like to test to make sure this stored procedure still works for Martin, because Martin should still have enough permission for this to run. So Execute dbo.securityTest. And that still runs for Martin. I'm anticipating this will not work properly for John.

Let's go ahead and test that. I'm going to logout as Martin, log back in as John. John can still see the stored procedure, but when he tries to execute the stored procedure, it gives the error: The SELECT permission was denied on the object "Authors". So now, because the stored procedure and the authors table have different owners, the permissions are not passed back and forth the same way. And John is no longer able to query that from the stored procedure, even though he has permission to the stored procedure.

In this case, he would also need permission to the underlying table. So the hypothetical, we were working through, we first stored this, now we want to allow access to John, will only work if both items are owned by the same owner. So now let's do a little housekeeping to clean up some of the changes we made here. First of all, I'm going to logout as John, because the remainder of the work I want to do as a different user. I'll log back in as myself. And we should see the authors table is still owned by Martin.

I'll prefer to put it back to be and owned by dbo. And if you want your environment to match mine, go ahead and execute the code that's on the screen and make sure it's Martin.Authors. And when we refresh, yes; we should see that is now owned again by dbo and it will remain that way for the remainder of our course.