Let’s talk more on Federation model and also on the modern authentication for SharePoint online  now. In the case of federated environment, once you sign with your organization account to SharePoint online and if your account is federated, Web client redirects the request from login.microsoft.com to On-premises ADFS/other 3^rd party federation engine.

The Azure AD authentication endpoint will detect if the particular account is federated if so, does another redirection to the internal federation service (which can be either ADFS or anything) Federation service requires the client to authenticate. Once authenticated, federation services will retrieve the necessary claims related information from Active Directory and provide the web client with a token holding the claims about the user. The client will present the token to Azure AD and after successful authentication, the web client will be redirected back to Microsoftonline.com.

To understand more on how user profile synchronization works, please refer

Now let’s see what is modern authentication is all about:

Though this has got nothing to do in SharePoint online, this is mainly for office 365 Apps.

Modern authentication brings Active Directory Authentication Library (ADAL)-based sign-in to Office client apps across platforms. This enables sign-in features such as Multi-Factor Authentication (MFA), SAML-based third-party Identity Providers with Office client applications, smart card and certificate-based authentication, and it removes the need for Outlook to use the basic authentication protocol.

By enabling ADAL for Office client applications, they will use an in-application browser control to render the Azure AD sign in experience in the same fashion as browser-based Office 365 clients like the Outlook on the Web (OotW). ADAL based OAuth authentication works for federated as well as non-federated scenarios.

To know more on session timeout for office 365 services please refer (this might differ based on our organization internal federation system setting)

The row level security (RLS) provides security based on the user name or login id of the current user logged in. While executing the select statement the rows are filtered based on the executing context of the query. Previous we have applied the filtered in a views or through a stored procedure, whereas the filtered will not be applied at the table level.

The table will have a security policy filter which will be executed, whereas the admin can view all the rows and others can view the data based on the security policy.

 CREATE TABLE Orders (Id INT IDENTITY(1,1) PRIMARY KEY,
 Name VARCHAR(100),OrderQuanity INT , Price  DECIMAL(10,2),UserName VARCHAR(50))
 GO
 
 INSERT INTO dbo.Orders VALUES ('Order1',10,100,'User1'),
 							('Order2',6,2.35,'User1'),
 							('Order3',5,34.23,'User2'),
 							('Order4',7,199,'User2'),
 							('Order5',12,199,'User3')
 GO

For a row level security we need to create a function & Security policy

Function for filtering the rows

This function uses the @username parameter and the value as current user using the function USER_NAME which will filter the rows with the current username. We need to associate the function to the table using a security policy.

 CREATE FUNCTION fn_orderSecurity (@userName sysname)
 RETURNS TABLE
 WITH SCHEMABINDING
 AS
 RETURN SELECT 1 AS 'orderSecurity' WHERE @userName=USER_NAME()
 
 GO

Creating a security policy

 CREATE SECURITY POLICY order_policy 
 ADD FILTER PREDICATE dbo.fn_orderSecurity(UserName) 
 ON dbo.orders 
 WITH (STATE=ON)

In the security policy above the FILTER PREDICATE is referencing the function dbo.fn_orderSecurity.  By use of the security policy the SQL Server will make sure that every time that a database user runs a SQL command that referred the orders table has the filter predicate ‘orderSecurity’ function will also be executed, thus enforcing the RLS.

 GRANT SELECT ON dbo.Orders TO PUBLIC
 
 CREATE USER user1 WITHOUT LOGIN
 CREATE USER user2 WITHOUT LOGIN
 CREATE USER user3 WITHOUT LOGIN
 
 EXEC ('Select * from orders') AS USER='User1'
 
 EXEC ('Select * from orders') AS USER='User2'
 
 EXEC ('Select * from orders') AS USER='User3'

 Alter Security Policy order_policy with (State = off)
 
 EXEC ('Select * from orders') AS USER='User3'

 SELECT * FROM sys.security_policies
 GO
 SELECT * FROM sys.security_predicates
 GO

 Drop Security Policy IF EXISTS fn_security
 Drop FUNCTION IF EXISTS dbo.fn_securitypredicateOrder