Fix Session Context Key set as Read_Only

[M4Al]

Why make this change?

• Fixes [Bug]: MSSQL (and related) - EXEC sp_set_session_context is executed with @read_only = 1 #2341 (partly)
  • do not set the session context in SQL server with read_only = 1 as this prevents us from doing a second request on the same connection
  • keep a copy of the original 'roles' from the JWT token so we can use it on the SQL Filter Predicate to accurately implement row level security

What is this change?

The changes itself are quite simple and should break nothing, see the diff :-)

How was this tested?

I have not created/adapted any tests yet. Just looking for comments before I go there.

Sample Request(s)

Sample of a JWT token (only the relevant part)

{
  "aud": "api://ddcf6b31-5d01-407d-97cf-8efefc455d32",
  "iss": "https://sts.windows.net/9215c785-95c3-49b0-bdba-2062df5aedb5/",
  "roles": [
    "user",
    "Allow_Customer_OPS025235",
    "Allow_Customer_OPS004095"
  ],
  "ver": "1.0"
}

X-MS-API-ROLE: user

before my change the extra 'roles' that do not match the X-MS-API-ROLE header would never reach the database context.
With my change you can do things like this in SQL Predicates to filter out only subsets of the data:

CREATE FUNCTION dbo.ops_fact_order_Predicate(@CustomerNo varchar(max))
RETURNS TABLE
WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @CustomerNo in (
		select trim(replace(replace(replace([value], '"', ''), ']', ''), 'Allow_Customer_', '')) 
		from STRING_SPLIT ( 
			CAST(SESSION_CONTEXT(N'original_roles') as varchar(max)) 
			, ',' 
			, 0) 
			where trim(replace(replace([value], '"', ''), ']', '')) like 'Allow_Customer%'
		)

CREATE SECURITY POLICY dbo.ops_fact_order_Policy
ADD FILTER PREDICATE dbo.ops_fact_order_Predicate(CustomerNo)
ON [gold_ops].[ops_fact_order];

[Aniruddh25]

Thanks for this smart change to provide the original roles for additional filtering. Left a few nit comments and some questions, looks good to merge otherwise!

[Aniruddh25]

/azp run

[Aniruddh25]

The original PR contained fewer changes, please restrict the changes to the purpose of the PR and lets not add additional changes in the same PR. Waiting for removing the unnecessary changes

[abhishekkumams]

@M4Al , let us know if you would be able to address the comments...

[JerryNixon]

@Aniruddh25 is this something we could wrap?

[Aniruddh25]

@Aniruddh25 is this something we could wrap?

The original PR was useful. It now contains additional changes which are not really necessary like $top, DwSQL builder changes. We need to clean those up before merging this in.
@RubenCerna2079, could you please take this task up?

[Aniruddh25]

@M4Al, we will take this PR forward and merge from here.

[RubenCerna2079]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[RubenCerna2079]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[RubenCerna2079]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[RubenCerna2079]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[RubenCerna2079]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[Aniruddh25]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[Aniruddh25]

The current changes look good. However, the description and title need to be fixed to reflect the 3 fixes this PR is targeting:

1. fixing session context to be not read only
2. maintaining original_roles from the claim
3. adding recordCount value to GraphQL query returns

[Aniruddh25]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[Aniruddh25]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).