Question

I have an application running in IIS which connects to a SQL Server 2008 R2 instance using windows integrated authentication. This application does simple read/write operations in the db using a set of stored procedures. I can restrict the privileges in SQL server quite well for this login/user combination.

But for a small subset of the application I need “elevated”/more powerful permissions in the database … for example creating/dropping event notification and possibly queues and broker services.

So basically I have a single process with code running under the same user account connecting to SQL server, and I need two different sets of privileges … one connection with very restricted permissions, one connection with more powerful privileges.

I would like to use windows integrated authentication … sql authentication with two user/password combos is not an option.

Is there a recommended way to achieve this?

• Impersonation in the application code, connecting to SQL Server using integrated security from an impersonated context (different user account/sql login) don’t like it since I have to manage a second login/password
• SQL server application roles (requires a application provided password I believe) – don’t really like it since I need to store passwords
• SQL authentication with two users – not an option
• create dedicated stored procedures for the “elevated stuff” and use execute as (should work, however, not sure whether I can create stored procedures in the target db)
• complicated idea: start the application process, connect to the db, restrict the application token and then open the less privileged connection (would that work?)
• use COM+ (a la Keith Brown’s protocol transition), WCF service, or second process for the “elevated” parts of the application (too complex)

I suppose there is some simple and neat solution which I am missing …

Answer 1

Use code signing. All your ‘elevated’ operations are done from stored procedures that are signed, and the trust is derived from the signature of the procedure. This is quite effective and powerful, and extremely secure. For instance, say you need a way to, I don’t know, create a queue and a service that is bound to the http://schemas.microsoft.com/SQL/Notifications/PostEventNotification contract. So you need to run the following code:

create queue myQueue;
create service myService on queue myQueue (
[http://schemas.microsoft.com/SQL/Notifications/PostEventNotification]);

This statements would require elevated permissions: CREATE QUEUE, CREATE SERVICE and REFERENCE on the EN contract. You can embed these statements in a procedure, you sign the procedure, you create a user from the certificate used to sign the procedure and then you grant the necessary privileges to the certificate derived user:

create procedure usp_createQueueAndService
with execute as caller
as
begin
    create queue myQueue;
    create service myService on queue myQueue (
    [http://schemas.microsoft.com/SQL/Notifications/PostEventNotification]);
end
go

create certificate [certificateToSign_usp_createQueueAndService]
 ENCRYPTION BY PASSWORD = 'Password#1234'
 with subject = 'Code signing for usp_createQueueAndService';
go

ADD SIGNATURE TO OBJECT::[usp_createQueueAndService]
BY CERTIFICATE [certificateToSign_usp_createQueueAndService]
WITH PASSWORD = 'Password#1234';
go

ALTER CERTIFICATE [certificateToSign_usp_createQueueAndService]
REMOVE PRIVATE KEY;
GO

create user [certificateDerivedUser_usp_createQueueAndService]
from certificate [certificateToSign_usp_createQueueAndService];
go

grant create queue to [certificateDerivedUser_usp_createQueueAndService];
grant create service to [certificateDerivedUser_usp_createQueueAndService];
grant references on 
    contract::[http://schemas.microsoft.com/SQL/Notifications/PostEventNotification] 
    to [certificateDerivedUser_usp_createQueueAndService];
go

This is 100% bullet proof security. All callers that have granted EXECUTE permission on the procedure can now create the queue and service, because the procedure itself is granted the necessary privileges via the signature. Nobody can modify the procedure, because ALTERing the procedure loses the signature and thus loses the privileges. Nobody can abuse the certificate to sign another procedure because the private key was dropped and forever lost (the private key is not needed to verify existing signatures).

This model can be extended to any privileges you need, including server wide privileges (requires a certificate derived login instead of user though, see Signing and Activated Procedure).

Of course you can have the usp_createQueueAndService accept the queue and service name as parameters, I left that part as a simple exercise for the reader. If you want to play with Event Notifications, such kind of exercises should be trivial for you 😉