How to parameterise a SQL REVOKE command - asp.net

Question

How can I parameterise a SQL REVOKE command?
DECLARE #ViewName nvarchar = 'MyViewName'
DECLARE #UserRole nvarchar = 'MyRoleName'
REVOKE SELECT ON [#ViewName] TO [#UserRole]
Outputs the following error:
Cannot find the object '#ViewName', because it does not exist or you do not have permission.`
Do I need to use Dynamic SQL to solve this or is there another way?
My actual Use Case is in ASP.NET SqlDataClient and the code is being generated, so I have limited control over it. The code being sent to SQL (sniffed by SQL Profiler) is:
exec sp_executesql N'REVOKE SELECT ON [#ViewName] TO [#UserRole]',N'#ViewName nvarchar(24),#UserRole nvarchar(12)',#ViewName=N'MyViewName',#UserRole=N'MyUserRole'

Answer 1

Because GRANT and REVOKE require considerable permissions themselves, it's usually attractive to do this in a stored procedure that builds the dynamic SQL and can execute the commands under a different credential. That way you can selectively assign the right to REVOKE by controlling access to the stored procedure, add auditing if this ever becomes a requirement, and last but not least you can keep using parameters.
In this case:
CREATE PROCEDURE dbo.RevokeSelect(#ObjectName NVARCHAR(128), #RoleName NVARCHAR(128))
WITH EXECUTE AS OWNER AS BEGIN
SET NOCOUNT ON;
DECLARE #SQL NVARCHAR(MAX);
SELECT #SQL = REPLACE(REPLACE(
N'REVOKE SELECT ON #ObjectName TO #RoleName;',
'#ObjectName', QUOTENAME(#ObjectName)),
'#RoleName', QUOTENAME(#RoleName))
;
-- For debugging
--PRINT #SQL
EXEC (#SQL)
END;
GO
GRANT EXECUTE ON dbo.RevokeSelect TO [application_login];
Thanks to EXECUTE AS OWNER, the [application_login] account needs no additional permissions; it can REVOKE SELECT on any object in the database through the stored procedure. This can be exactly what you want, but if it's not, you should remove EXECUTE AS OWNER and grant individual CONTROL permission on the objects (but this, of course, allows lots of other operations as well).
Take care that a procedure that performs dynamic SQL needs careful review to ensure it's not susceptible to SQL injection, just like anything else that uses dynamic SQL. Obviously this is even more important if the procedure uses EXECUTE AS OWNER, since it could do anything. In this case, applying QUOTENAME to both parameters takes care of that.
Last but not least, while EXECUTE AS OWNER is simple and convenient, it will fail if the database owner is not an account but a group. In this case, if you want to delegate permissions, you'll have to create a proxy account for use in EXECUTE AS or sign the stored procedure with a certificate. You may want to do this anyway if developers can't be trusted with the power of EXECUTE AS OWNER. That goes beyond the scope of this answer, but Erland Sommerskog has an excellent writeup on this topic.