Scribd
Upload
81 views6 pages

SQL Server Row Level Security by Example

SQL Server Row Level Security (RLS) allows controlling access to rows in a table based on user characteristics. This example uses RLS to restrict advisors to viewing only their assigned students, while the principal can view all students. RLS is implemented by creating a security schema and function to check the user, then enabling a policy on the student table to filter rows using this function. Queries run as different users demonstrate each user only seeing relevant student records.

Uploaded by

Ajay Kumar Dwivedi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
81 views6 pages

SQL Server Row Level Security by Example

SQL Server Row Level Security (RLS) allows controlling access to rows in a table based on user characteristics. This example uses RLS to restrict advisors to viewing only their assigned students, while the principal can view all students. RLS is implemented by creating a security schema and function to check the user, then enabling a policy on the student table to filter rows using this function. Queries run as different users demonstrate each user only seeing relevant student records.

Uploaded by

Ajay Kumar Dwivedi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

SQL Server Row Level Security by Example

https://www.sqlnethub.com/blog/sql-server-2016-row-level-security/

SQL Server Row Level Security (RLS) is one of the top new features shipped in SQL Server 2016. With RLS, you can control access
to rows in a table based on the characteristics of the user executing a query.

The access restriction logic is located in the database tier and access restrictions are always applied, thus they cannot be skipped.

SQL Server Row Level Security by Example

• Below I will showcase SQL Server Row-Level Security with the use of a simple scenario.
• This example features a fictitious school’s database and more specifically a table containing the school’s student records.
Each student is assigned an advisor.
• By using Row-Level Security, it is possible for each advisor to see only the records of his students.
• In the same scenario, only the school principal can view all student records.

--
-- Row Level Security Example
--

USE master;
GO

--Create sample database


CREATE DATABASE RLSDemoDB;
GO

--Use the sample database


USE RLSDemoDB;
GO

--Create four database users


CREATE USER Advisor1 WITHOUT LOGIN;
CREATE USER Advisor2 WITHOUT LOGIN;
CREATE USER Advisor3 WITHOUT LOGIN;
CREATE USER Principal WITHOUT LOGIN;

--Create the students table


CREATE TABLE tblStudents
(
code VARCHAR(10) NOT NULL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
advisorCode sysname,
classID INT,
GPA FLOAT
);

--Insert sample data


INSERT tblStudents
VALUES ( 'ST001', 'Student1','Advisor1', 1,3.2),
( 'ST002', 'Student2','Advisor1', 3,3.3),
( 'ST003', 'Student3','Advisor1', 5,2.8),
( 'ST004', 'Student4','Advisor2', 2,3.9),
( 'ST005', 'Student5','Advisor2', 4,3.1),
( 'ST006', 'Student6','Advisor2', 5,1.8),
( 'ST007', 'Student7','Advisor3', 6,2.2),
( 'ST008', 'Student8','Advisor3', 4,3.7),
( 'ST009', 'Student9','Advisor3', 3,3.6),
( 'ST010', 'Student10','Advisor4',2,3.5)
GO
Let’s check the table contents before enabling the security policy:

Now let’s grant SELECT access to all users which are the three advisors and the principal:

--Grant SELECT access to users


GRANT SELECT ON tblStudents TO Advisor1;
GRANT SELECT ON tblStudents TO Advisor2;
GRANT SELECT ON tblStudents TO Advisor3;
GRANT SELECT ON tblStudents TO Principal;
GO

Now it’s time to create the Security policy. First we have to create the schema:

--Create security schema


CREATE SCHEMA Security;
GO

Then, we need to create the function that will be used for checking the executing user:

--Create function that checks the executing user


CREATE FUNCTION Security.fn_securitypredicate(@advisorCode AS sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @advisorCode= USER_NAME() OR USER_NAME() = 'Principal';
GO

Finally we create and enable the security policy which uses the schema and the function created above:

--Create security policy


CREATE SECURITY POLICY StudentFilter
ADD FILTER PREDICATE Security.fn_securitypredicate(advisorCode)
ON dbo.tblStudents
WITH (STATE = ON);
GO
Now let’s retrieve the records from the the tblStudents table, each time within the context of a different user (i.e. advisor1,
advisor2, advisor3 and principal).

If we execute the above query as the user ‘Advisor1‘ we can only see the student records that have ‘Advisor1’ as their advisor:

If we execute the above query as the user ‘Advisor2‘ we can only see the student records that have ‘Advisor2’ as their advisor:

If we execute the above query as the user ‘Advisor3‘ we can only see the student records that have ‘Advisor3’ as their advisor:
If we execute the above query as the user ‘Principal‘ we can see all student records:

If we disable the policy, then we return to the original state where all the records are retrieved from the tblStudents table within
the context of any user that was granted the SELECT permission on the table:
From the above example you can see that it’s quite easy to control access to your data at the most granular level in the database,
that is the record level, by using Row-Level Security in SQL Server 2016 or later.

You might also like