-
Notifications
You must be signed in to change notification settings - Fork 267
Fix Session Context Key set as Read_Only & maintain original roles from the JWT token #2344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!
/azp run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@M4Al , let us know if you would be able to address the comments... |
@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. |
@M4Al, we will take this PR forward and merge from here. |
Added a new constant `ORIGINAL_ROLE_CLAIM_TYPE` in `AuthenticationOptions.cs` to store the original roles claim type. Modified `AuthorizationResolver` to preserve the original 'roles' claim by adding it to the `resolvedClaims` dictionary under the new key. Changed `MsSqlQueryExecutor` to set session context parameters with `@read_only = 0` to allow modifications.
This reverts commit 08f741c.
remove trailing space Co-authored-by: Aniruddh Munde <[email protected]>
/azp run |
Azure Pipelines successfully started running 6 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 6 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 6 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you for fixing this!
/azp run |
Azure Pipelines successfully started running 6 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/azp run |
Azure Pipelines successfully started running 6 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 6 pipeline(s). |
…om the JWT token (#2344) ## Why make this change? - Fixes #2341 - The session context in SQL server is `read_only = 1` which prevents users from doing multiple requests on the same connection. - The row level security is not accurately implemented when using a JWT token. ## What is this change? Changes the session context from `read_only = 1` to `read_only = 0` to allow multiple requests to be done in the same connection, Creates a copy of the original 'roles' from the JWT token to use it on the SQL Filter Predicate to accurately implement row level security. ## How was this tested? - [ ] Integration Tests - [x] Unit Tests Updated `AuthorizationResolver` tests to ensure the original roles copy is working properly. ## 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]; ``` --------- Co-authored-by: KobeLenjou <[email protected]> Co-authored-by: Aniruddh Munde <[email protected]> Co-authored-by: Ruben Cerna <[email protected]> Co-authored-by: RubenCerna2079 <[email protected]>
…om the JWT token (#2344) ## Why make this change? - Fixes #2341 - The session context in SQL server is `read_only = 1` which prevents users from doing multiple requests on the same connection. - The row level security is not accurately implemented when using a JWT token. ## What is this change? Changes the session context from `read_only = 1` to `read_only = 0` to allow multiple requests to be done in the same connection, Creates a copy of the original 'roles' from the JWT token to use it on the SQL Filter Predicate to accurately implement row level security. ## How was this tested? - [ ] Integration Tests - [x] Unit Tests Updated `AuthorizationResolver` tests to ensure the original roles copy is working properly. ## 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]; ``` --------- Co-authored-by: KobeLenjou <[email protected]> Co-authored-by: Aniruddh Munde <[email protected]> Co-authored-by: Ruben Cerna <[email protected]> Co-authored-by: RubenCerna2079 <[email protected]>
## Why make this change? - The 1.6 release is missing the implementation for the File Sink feature, as well as the bug fixes to fix the session context and fix implementation of row-level security when users use a JWT token. ## What is this change? Cherry-picked PRs: - File Sink: - #2752 - #2825 - #2818 - Bug Fix: - #2344 ## How was this tested? - [ ] Integration Tests - [X] Unit Tests --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: M4Al <[email protected]> Co-authored-by: KobeLenjou <[email protected]> Co-authored-by: Aniruddh Munde <[email protected]>
Why make this change?
read_only = 1
which prevents users from doing multiple requests on the same connection.What is this change?
Changes the session context from
read_only = 1
toread_only = 0
to allow multiple requests to be done in the same connection,Creates a copy of the original 'roles' from the JWT token to use it on the SQL Filter Predicate to accurately implement row level security.
How was this tested?
Updated
AuthorizationResolver
tests to ensure the original roles copy is working properly.Sample Request(s)
Sample of a JWT token (only the relevant part)
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: