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