Raul Garcia's blog : SQL Server Signatures

Dynamic SQL and digital signatures in SQL Server 2005

raulga — Wed, 09 May 2007 21:42:00 GMT

As I already mentioned, dynamic SQL is a quite powerful, but also quite dangerous. In SQL Server 2005 we introduced a new feature that is also quite powerful and when used properly can be quite useful; but it is important to learn and understand any such feature in order to use it properly. In this small article I will describe a little bit more about the interaction between these two features.

First, I will describe briefly digitally signing modules in SLQ Server 2005, but this explanation will not be thorough, so I strongly recommend reading the references I include at the end of the article to learn more about this subject. After that I will explain how digital signatures affect dynamic SQL, what are the pitfalls you should try to avoid.

Digitally signing modules

Hopefully you are familiar with the concept of digital signatures. In SQL server 2005 we introduced digital signatures for modules, the concept per se is not far from the one you may be familiar with: have a piece of data (in this case I will talk about a T-SQL module) and use a digital certificate and its private key to create a signature; this signature and its relationship with the certificate can be used to a) verify that the original piece of data has not been modified since it was signed and b) that the data was signed by the owner of the give certificate.

Before SQL server 2005 there were very few reliable mechanisms to verify that the code issued by any ISV was not tampered. While typically not a problem for the consumer of the module as sysadmins and DBOs typically have good control (based on permissions and roles) on who can write executable modules (SPs, UDFs, etc.), ISVs have sometimes difficulties validating any unsupported modifications to their applications.

In SQL Server 2005, it is possible for ISVs to deliver digitally signed modules to their customers without granting any additional permissions or privileges based on the signature itself. This may allow them to help in support scenarios where customers (either by mistake or as an explicit act from a rogue employee) modified a module and their application is in an unsupported state. For example:

CREATE CERTIFICATE [cert_demo01]

WITH SUBJECT = 'Cert demo - simple siganture'

CREATE PROC [sp_demo01]

PRINT 'hello world'

ADD SIGNATURE TO [sp_demo01] BY CERTIFICATE [cert_demo01]

-- Let's see the signature

declare @thumb varbinary(32)

select @thumb = thumbprint from sys.certificates where name = 'cert_demo01'

select object_name(major_id) as 'object_name',

crypt_property as signature

from sys.crypt_properties where thumbprint = @thumb

-- Now alter the module to verify that the signature is gone

ALTER PROC [sp_demo01]

PRINT 'hello world again'

-- Let's see the signatures again... should be empty

declare @thumb varbinary(32)

select @thumb = thumbprint from sys.certificates where name = 'cert_demo01'

select object_name(major_id) as 'object_name',

crypt_property as signature

from sys.crypt_properties where thumbprint = @thumb

Another common issue DB administrators may face is the requirement to allow users o access some of the resources (such as tables) only via limited modules (i.e. users who should be able to execute an application, should not be able to access the tables directly). In SQL Server 2000, the common mechanism to achieve this was ownership chaining (OC), but OC has a lot of limitations because of its own nature (limited to DML, permissions are completely bypassed, security considerations for allowing cross-DB OC, etc.).

In SQL Server 2005, using digital signatures can be used to modify the execution context and add a user (mapped from the certificate) as a secondary identity that will affect the permission checks for the duration of the module (without bleeding to a subsequent module). Another way to explain this usage of signatures is to “extend permissions via signature” or “granting permission to the module”. In the following example I have some additional explanations in the comments:

CREATE CERTIFICATE [cert_demo02] WITH SUBJECT = 'Cert demo - signature as secondary identity'

-- Create a schema to store all resources, and a loginless user to be the schema owner

CREATE USER [usr_resources_owner] WITHOUT LOGIN

CREATE SCHEMA [sch_resources] AUTHORIZATION [usr_resources_owner]

-- Create a schema to store all modules, and a loginless user to be the schema owner

-- this will break Ownership chaining

CREATE USER [usr_module_owner] WITHOUT LOGIN

CREATE SCHEMA [sch_modules] AUTHORIZATION [usr_module_owner]

-- mCreate a simple table

CREATE TABLE [sch_resources].[t_Demo02]( data nvarchar(100) )

-- and a module to access it

CREATE PROC [sch_modules].[sp_demo02]

SELECT * FROM sys.user_token ORDER BY usage, type, name

SELECT * FROM [sch_resources].[t_Demo02]

-- Add a siganture to the newly created module

ADD SIGNATURE TO [sch_modules].[sp_demo02] BY CERTIFICATE [cert_demo02]

-- Create a user for our signing cert, but no permissions granted yet

CREATE USER [usr_cert_demo02] FOR CERTIFICATE [cert_demo02]

-- Now let's create a low-privielged user to test our module

CREATE USER [usr_lowpriv] WITHOUT LOGIN

GRANT EXECUTE ON [sch_modules].[sp_demo02] TO [usr_lowpriv]

-- Let's see what happens when the low priv user executes the module:

EXECUTE AS USER = 'usr_lowpriv'

EXEC [sch_modules].[sp_demo02]

-- What happened?

-- We can see that the user token during the module execution is different than

-- the token outside the call (below).

-- The signature is affecting the execution context based on the module siganture

-- and any permissions granted to the signing certificate will be added to the token.

SELECT * FROM sys.user_token ORDER BY usage, type, name

REVERT

-- Grant permission to access the table to the certificate

GRANT SELECT ON [sch_resources].[t_Demo02] TO [usr_cert_demo02]

-- and run the script from above again

-- Let's see what happens when the low priv user executes the module:

EXECUTE AS USER = 'usr_lowpriv'

EXEC [sch_modules].[sp_demo02]

REVERT

-- Now, it is impornat to notice that the siganture is added to the current token

-- not completetly replaced, and it is also importnat to notice that the permission checks

-- will still be evaluated based on this token (i.e. OC will bypass permission checks).

CREATE USER [usr_DeniedPrivs] WITHOUT LOGIN

-- Permission to execute the module, but not to access the table

DENY SELECT ON [sch_resources].[t_Demo02] TO [usr_DeniedPrivs]

GRANT EXECUTE ON [sch_modules].[sp_demo02] TO [usr_DeniedPrivs]

-- Should fail to select from table thanks to the DENY permission

EXECUTE AS USER = 'usr_DeniedPrivs'

EXEC [sch_modules].[sp_demo02]

REVERT

Digital signatures and dynamic SQL

Using the digital signature as a mechanism to extend permissions affects any operation on the body of the signed module, including dynamic SQL executed in it. What does it mean? It means that the signer should understand that the module to be signed will execute dynamic code that is also going to be signed. For example:

CREATE PROC [sch_modules].[sp_demo03] ( @Id int )

DECLARE @cmd nvarchar(max)

DECLARE @params nvarchar(max)

-- the follwoing code will be also afected by the siganture

SET @cmd = 'SELECT * FROM sys.user_token ORDER BY usage, type, name; SELECT * FROM [sch_resources].[t_Demo02] WHERE Id = @Id;'

SET @params = '@Id int'

EXEC sp_executesql @cmd, @params, @Id = @Id

-- Add a siganture to the newly created module

ADD SIGNATURE TO [sch_modules].[sp_demo03] BY CERTIFICATE [cert_demo02]

GRANT EXECUTE ON [sch_modules].[sp_demo03] TO [usr_lowpriv]

-- Let's see what happens when the low priv user executes the module:

EXECUTE AS USER = 'usr_lowpriv'

-- Will succeed

EXEC [sch_modules].[sp_demo03] 2

REVERT

This characteristic is a useful one, but it can also be dangerous in case of an arbitrary code execution or SQL injection. In the following example I will try to demonstrate these dangers in case of an injection.

-- The following module is subject to SQL injection

CREATE PROC [sch_modules].[sp_demo04] ( @Table_name sysname )

------------------------------------------------------------

-- WARNING: The following code is subject to SQL injection!!!

------------------------------------------------------------

DECLARE @cmd nvarchar(max)

-- the follwoing code will be also afected by the siganture

SET @cmd = 'SELECT * FROM sys.user_token ORDER BY usage, type, name; SELECT * FROM '

+ @table_name

EXEC ( @cmd )

-- Add a siganture to the newly created module

ADD SIGNATURE TO [sch_modules].[sp_demo04] BY CERTIFICATE [cert_demo02]

GRANT EXECUTE ON [sch_modules].[sp_demo04] TO [usr_lowpriv]

EXECUTE AS USER = 'usr_lowpriv'

-- Using the module as originally intented

EXEC [sch_modules].[sp_demo04] '[sch_resources].[t_Demo02]'

-- .. but now abusing the signature...

EXEC [sch_modules].[sp_demo04] '[sch_resources].[t_Demo02]; EXEC sp_addrolemember ''db_owner'', ''usr_lowpriv'';'

-- Notice that the attack failed thanks to the

-- limited permissions granted to the certificate.

-- This is one of the reasons why I always recommend

-- following the least privilege principle

REVERT

-- Now, what would happen if we would have granted

-- a much higher permission?

GRANT CONTROL TO [usr_cert_demo02]

EXECUTE AS USER = 'usr_lowpriv'

-- Your DB would be compromised!!!

EXEC [sch_modules].[sp_demo04] '[sch_resources].[t_Demo02]; SELECT * FROM fn_my_permissions( NULL, ''DATABASE''); print ''Insert your favorite attack here'''

REVERT

-- remove the extremely-high privilege from the cert

REVOKE CONTROL TO [usr_cert_demo02]

As you can see from the example, it is a good idea to follow the least-privilege principle when using signatures as a mechanism to extend the execution context.

Now, the natural question to follow: Why would SQL Server allow carrying the signature to dynamic SQL? The answer is not as simple, and I am sure there may be some people who won’t like it, but the truth is that SQL Server is a platform and digital signatures is a feature that, when used properly and responsibly, can be extremely useful and safe, and in case the application developer really don’t want to execute dynamic SQL with a signature, there is an alternative: Move the dynamic SQL to a non-signed module (the signature will not be carried to a different module). For example:

-- Based on demo04 and still carrying injectable dynamic SQL

CREATE PROC [sch_modules].[sp_demo05_dyn] ( @Table_name sysname )

------------------------------------------------------------

-- WARNING: The following code is subject to SQL injection!!!

------------------------------------------------------------

DECLARE @cmd nvarchar(max)

-- the follwoing code will be also afected by the siganture

SET @cmd = 'SELECT * FROM sys.user_token ORDER BY usage, type, name; SELECT * FROM ' + @table_name

EXEC ( @cmd )

CREATE PROC [sch_modules].[sp_demo05] ( @Table_name sysname )

SELECT * FROM sys.user_token ORDER BY usage, type, name;

SELECT * FROM [sch_resources].[t_Demo02];

-- Call the module that will do dynamic SQL

-- Noticed that the signature will be lost

EXEC [sch_modules].[sp_demo05_dyn] @table_name

ADD SIGNATURE TO [sch_modules].[sp_demo05] BY CERTIFICATE [cert_demo02]

GRANT EXECUTE ON [sch_modules].[sp_demo05] TO [usr_lowpriv]

-- Let's see what happens when the low priv user executes the module:

EXECUTE AS USER = 'usr_lowpriv'

-- The signature is not carried to the 2nd module as we intended

EXEC [sch_modules].[sp_demo05] '[sch_resources].[t_Demo02];'

REVERT

Conclusions

Digital signatures in SQL Server 2005 are a quite powerful tool, but as any such tool, it has to be used with care to avoid unnecessary risks and potential damage. When using digital signatures remember to be careful on what you are signing, and be extra careful when signing a module that includes dynamic SQL as it will be affected by the signature. Don’t sign unnecessary code, and keep the escalated (signed) code to a minimum.

I also strongly suggest following the least-privilege principle when using signatures. Grant the minimum permission necessary to the certificate, and if necessary, split the code and sign different pieces of the code by different certificates.

Additional references

From BOL:

· Module Signing (http://msdn2.microsoft.com/en-us/library/ms345102.aspx)

· Understanding Execution Context (http://msdn2.microsoft.com/en-us/library/ms187096.aspx)

Laurentiu Cristofor’s blog:

· SQL Server 2005: procedure signing demo (http://blogs.msdn.com/lcris/archive/2005/06/15/429631.aspx)

· SQL Server 2005: An example for how to use counter signatures (http://blogs.msdn.com/lcris/archive/2006/10/19/sql-server-2005-an-example-for-how-to-use-counter-signatures.aspx)

I hope this article will be useful. Please let me know either here in the blog comments or in the SQL Server Security forum () if you have any feedback or comments on this topic.

Using a digital signature as a secondary identity to replace Cross database ownership chaining

raulga — Tue, 31 Oct 2006 05:53:00 GMT

In SQL Server 2000, Cross database ownership chaining (CDOC) was a mechanism used to allow access (DML access) to resources on different DBs without explicitly granting access to the resources (such as tables) directly.

Unfortunately CDOC is a feature that Microsoft does not recommend as it has some serious security risks inherent to the feature (for details on this topic, you can consult BOL, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_security_4iyb.asp).

Fortunately in SQL Server 2005 we count with 2 alternative mechanisms that will enable cross-database resource usage without explicitly granting access to either the database or to the resources directly to each principal. These mechanisms are EXECUTE AS feature and using digital signatures.

Some of the best references on how to use these mechanisms can be found in BOL (Extending Database Impersonation by Using Execute As) and in

Laurentiu Cristofor’s blog (http://blogs.msdn.com/lcris/).

On this demo, I want to extend these materials with a demo that relies only on digital signatures as secondary identity (i.e. no authenticator involved).

While this approach has some advantages, including:

· No need to create/re-use a login for the application

· Works as a CDOC replacement

o In addition, works with dynamic SQL

· Denied permissions on the caller will be honored

· Easier to script for ISV applications (i.e. the signature can be precalculated)

· Can be easily adapted for either DB or server scoped permissions

As any other security feature, this approach also has some limitations you should consider before deploying:

· It doesn’t work if the calling context is a DB-scoped context (i.e. approles, EXECUTE AS USER).

· Doesn’t work if the operation requires creating an object or use the calling’s primary identity.

o Do not rely on implicit user creation!

· Be extra careful when using dynamic SQL as SQL injection attacks can abuse the escalated privileges.

· Need to write the certificate to disk (at least temporarily) in order to create the certificate in 2 or more databases.

· If you require calling nested modules, each one of the nested modules should be signed or counter signed as well.

Demo

/*******************************************************************

* This posting is provided "AS IS" with no warranties, and

* confers no rights.

* Author: Raulga

* Date: 10/30/2006

*******************************************************************/

CREATE DATABASE [db_Source]

CREATE DATABASE [db_Target]

CREATE LOGIN [dbo_db_Source] WITH PASSWORD = 'My S0uRc3 D8 p@55W0rD!'

CREATE LOGIN [dbo_db_Target] WITH PASSWORD = 'My +@r637 D8 p@55W0rD!'

-- Change the ownership for the source and the target databases

ALTER AUTHORIZATION ON DATABASE::[db_Source] to [dbo_db_Source]

ALTER AUTHORIZATION ON DATABASE::[db_Target] to [dbo_db_Target]

-- This principal will be the data owner, he can access the data on

-- the target database, and he controls the stored procedures on the

-- source database

CREATE LOGIN [data_owner] WITH PASSWORD = 'd@+4 0wn3R'

-- This principal should only have access to the data via the stored

-- procedures

CREATE LOGIN [AppUser] WITH PASSWORD = 's0m3 p@55w0Rd'

-----------------------------------------

-- Setting up the target DB

use [db_Target]

CREATE USER [data_owner] WITH DEFAULT_SCHEMA = [data_owner]

CREATE SCHEMA [data_owner] AUTHORIZATION [data_owner]

CREATE TABLE [data_owner].[MyTable]( data nvarchar(100) )

INSERT INTO [data_owner].[MyTable] values ( N'My data' )

-----------------------------------------

-- Setting up the source DB

use [db_Source]

-- The low privielged user is only required here

CREATE USER [AppUser]

-- Create an application that uses the table stored in db_Target

-- I will use a specific schema for all the application modules

CREATE SCHEMA [schema_MyApp]

GRANT EXECUTE ON SCHEMA::[schema_MyApp] TO [AppUser]

-- Remember that sigantures are sensitive to comments and white spaces

CREATE PROC [schema_MyApp].[sp_MyApp01] ( @new_data nvarchar(100) )

-- Print the user token on this DB

SELECT * FROM sys.user_token

-- Print the user token on the target DB

SELECT * FROM [db_Target].sys.user_token

-- Insert data on the Cross-DB table

INSERT INTO [db_Target].[data_owner].[MyTable] VALUES (@new_data)

-----------------------------------------------------

-- Test the application as the low privielged user,

EXECUTE AS LOGIN = 'AppUser'

-- The call should fail teh moment it tries to access db_Target

EXEC [schema_MyApp].[sp_MyApp01] N'Test data'

-- revert to original context

REVERT

-----------------------------------------------------

-- Now, let's play the role of db_target DBO

USE [db_Target]

EXECUTE AS LOGIN = 'dbo_db_Target'

-- Create our signing certificate

CREATE CERTIFICATE [cert_MyAppSecIdentity]

ENCRYPTION BY PASSWORD = 'S16n1n6 c3r+1f1C@+3'

WITH SUBJECT = 'myApp siging certificate'

-- Re-create the Proc exactly as it was created in the source DB

-- including comments and blank characters

CREATE SCHEMA [schema_MyApp]

CREATE PROC [schema_MyApp].[sp_MyApp01] ( @new_data nvarchar(100) )

-- Print the user token on this DB

SELECT * FROM sys.user_token

-- Print the user token on the target DB

SELECT * FROM [db_Target].sys.user_token

-- Insert data on the Cross-DB table

INSERT INTO [db_Target].[data_owner].[MyTable] VALUES (@new_data)

-- And add the siganture

ADD SIGNATURE TO [schema_MyApp].[sp_MyApp01] BY CERTIFICATE [cert_MyAppSecIdentity]

WITH PASSWORD = 'S16n1n6 c3r+1f1C@+3'

BACKUP CERTIFICATE [cert_MyAppSecIdentity] TO FILE = 'cert_MyAppSecIdentity.cer'

-- obtain the pre-calculated signature that can be applied to the module in db_Source

DECLARE @signature varbinary(max)

SELECT @signature = crypt_property FROM sys.crypt_properties WHERE major_id = object_id('[schema_MyApp].[sp_MyApp01]')

PRINT @signature

-- In my case the siganture value was:

-- 0x5EF9C30476A8E3E248E9E11B7563528EB02DA1D8F440CAA9141841B9F3101F1988760D2775000CD0D70F44A8672984E327FBF2676E7FAC9AAED8E6F383A98B2A569A407577917E671F3D632EF7326AD3770A32E05CF43A613D310D64B6D52FD978E57A73912BF3587C475E48F4AA58561A7E0DB5D9DB53D35E03EC281BEC7772

-- Let's create a user for teh certifcate so we can use it as a secondary identity

CREATE USER [cert_MyAppSecIdentity] FOR CERTIFICATE [cert_MyAppSecIdentity]

-- And grant the right permission to it, in thsi case INSERT on teh table would be sufficient

GRANT INSERT ON [data_owner].[MyTable] TO [cert_MyAppSecIdentity]

-- Let's look at the permissions for the certificate-mapped user:

SELECT * FROM sys.database_permissions WHERE [grantee_principal_id] = user_id( 'cert_MyAppSecIdentity' )

--... notice that in addition to INSERT on our table, this user also has CONNECT permission on the database

-- revert to original context

REVERT

-----------------------------------------------------

-- Now, let's play the role of db_Source DBO

USE [db_Source]

EXECUTE AS LOGIN = 'dbo_db_Source'

-- Let's create a copy of teh certifcate on this DB

CREATE CERTIFICATE [cert_MyAppSecIdentity] FROM FILE = 'cert_MyAppSecIdentity.cer'

-- Now use teh pre-calculated siganture to sign the app

-- Notice that the Source DB dbo doesn't have any access to trhe private key

-- therefore, she cannot modify the SP body

ADD SIGNATURE TO [schema_MyApp].[sp_MyApp01] BY CERTIFICATE [cert_MyAppSecIdentity]

WITH SIGNATURE = 0x5EF9C30476A8E3E248E9E11B7563528EB02DA1D8F440CAA9141841B9F3101F1988760D2775000CD0D70F44A8672984E327FBF2676E7FAC9AAED8E6F383A98B2A569A407577917E671F3D632EF7326AD3770A32E05CF43A613D310D64B6D52FD978E57A73912BF3587C475E48F4AA58561A7E0DB5D9DB53D35E03EC281BEC7772

-- revert to original context

REVERT

-----------------------------------------------------

-- Let's test the application as the low privielged user once more

EXECUTE AS LOGIN = 'AppUser'

-- The call should succeed!!!

EXEC [schema_MyApp].[sp_MyApp01] N'Test data'

-- revert to original context

REVERT

--0 NULL public ROLE GRANT OR DENY

--6 0x0106000000000009010000002A1A61C7FF8883632259BFA45D0493B234FDD3C1 cert_MyAppSecIdentity USER MAPPED TO CERTIFICATE GRANT OR DENY

-- Verify that the insert succeeded

SELECT * FROM [db_Target].[data_owner].[MyTable]

-----------------------------------------------------

-- 2nd part

-- Using dynamic SQL with access via siganture

-----------------------------------------------------

USE db_Source

EXECUTE AS LOGIN = 'dbo_db_Source'

-- Let's create a simple module that will execute a select & a simpel dynamic SQL code

CREATE PROC [schema_MyApp].[sp_MyApp02] ( @new_data nvarchar(100) )

-- SELECT from teh table

SELECT * FROM [db_Target].[data_owner].[MyTable]

-- Using dynamic SQL for demonstration purposes only

EXEC( 'use db_target; SELECT * FROM sys.user_token; SELECT user_name();' )

REVERT

--------------------------------------------

-- Now let's create the siganture for the previous module

USE [db_Target]

EXECUTE AS LOGIN = 'dbo_db_Target'

CREATE PROC [schema_MyApp].[sp_MyApp02] ( @new_data nvarchar(100) )

-- SELECT from teh table

SELECT * FROM [db_Target].[data_owner].[MyTable]

-- Using dynamic SQL for demonstration purposes only

EXEC( 'use db_target; SELECT * FROM sys.user_token; SELECT user_name();' )

ADD SIGNATURE TO [schema_MyApp].[sp_MyApp02] BY CERTIFICATE [cert_MyAppSecIdentity]

WITH PASSWORD = 'S16n1n6 c3r+1f1C@+3'

-- We need SELECT permission to succeed on the SP

GRANT SELECT ON SCHEMA::[data_owner] TO [cert_MyAppSecIdentity]

-- same step as before

DECLARE @signature varbinary(max)

SELECT @signature = crypt_property FROM sys.crypt_properties WHERE major_id = object_id('[schema_MyApp].[sp_MyApp02]')

PRINT @signature

-- 0x16A91194689EB9D07FB1DEB5526B1216126D79DF00B4C74CDC5D86CA94DF81732DB001C504DC7C361A3F4FC45214DA9A6484A085CDC1679E7C5D23EB0C2ADD9F118C26B20B3853CB8D329591E100BA742EFA5E47985623C8D0CF9BAE80AC488B09B42386010F079319FA241012A73BFD2E3BC214D527398B12EAB22316FC4A59

REVERT

------------------------------

USE db_Source

ADD SIGNATURE TO [schema_MyApp].[sp_MyApp02] BY CERTIFICATE [cert_MyAppSecIdentity]

WITH SIGNATURE = 0x16A91194689EB9D07FB1DEB5526B1216126D79DF00B4C74CDC5D86CA94DF81732DB001C504DC7C361A3F4FC45214DA9A6484A085CDC1679E7C5D23EB0C2ADD9F118C26B20B3853CB8D329591E100BA742EFA5E47985623C8D0CF9BAE80AC488B09B42386010F079319FA241012A73BFD2E3BC214D527398B12EAB22316FC4A59

-- Let's test the application as the low privielged user

EXECUTE AS LOGIN = 'AppUser'

-- The SELECT call should succeed!!!

EXEC [schema_MyApp].[sp_MyApp02] N'Test data'

-- Notice that the token inside the dynamic SQL also contains the certificate user as a secondary identity

-- Additionally, look at the result from user_name()!

-- The reason why it shows AppUser is because the access to teh DB is via a secondary identity, similar to the

-- case when access to a database is granted via a Windows group.

-- revert to original context

REVERT

-----------------------------------------------------

-- 3rd part

-- Honoring denied permissions

-----------------------------------------------------

CREATE LOGIN [dbTarget_DenyReader] WITH PASSWORD = '53cr3+ p@55WoRd!'

USE [db_Target]

CREATE USER [dbTarget_DenyReader]

-- This user cannot SELECT from [data_owner] schema

DENY SELECT ON SCHEMA::[data_owner] TO [dbTarget_DenyReader]

USE [db_Source]

-- But it is a valid, maybe even privielged user on db_Source

CREATE USER [dbTarget_DenyReader]

EXEC sp_addrolemember 'db_owner', 'dbTarget_DenyReader'

-- Can dbTarget_DenyReader use the application we created?

EXECUTE AS LOGIN = 'dbTarget_DenyReader'

-- This call will succeed, after all INSERT permission via teh certificate is still valid

-- and no explicit denied permission for INSERT

EXEC [schema_MyApp].[sp_MyApp01] N'Test data as deny reader'

-- Notice that on the user token for db_Target this time we can see "dbTarget_DenyReader"

-- The reason is that this time we are not accessing teh db_Target based on teh secondary identity

-- as dbTarget_DenyReader is a valid user on it, we are just extending the existing permissions.

-- Let's try the 2nd SP now...

EXEC [schema_MyApp].[sp_MyApp02] N'Test data as deny reader'

-- SELECT on [db_Target].[data_owner].[MyTable] failed,

-- but the rest of the module executed as we expected, you can see

-- that the certificate is still aprt of the token on the dynamic SQL call.

-- revert to original context

REVERT