MANAGEMENT OF

AUTHENTICATION AND
AUTORIZATION
GROUP MEMBERS

 BILL NELSON (GROUP LEADER)

 EPAH FONZOCK MANYI
 DONFACK TONFACK CHRISTIAN
 BAGARI AROUNA RAOUL
 DJOUMESSI DYLAN
DIFFERENT PARTS OF OUR
PRESENTATION
 AUTHENTICATION OF CONNECTION
 AUTHORIZATION OF LOGIN ACCOUNTS TO ACCESS A DATABASE
 AUTHORIZATION OF USERS TO ACCESS OBJECT
 AUTHORIZATION BETWEEN SERVERS
 PERMISSION OF USERS TO ACCESS CODE
1-AUTHENTICATION OF CONNECTION

 There are two different authentication methods for connecting to SQL

Server: Windows and SQL Server
 Windows authentication requires a user to first authenticate to Windows
with their login and password
 Once a user has been authenticated to Windows, they can then connect
to SQL Server using Windows authentication
 Setting up SQL Server to support
different authentication modes

When installing SQL Server, you have the choice to support only
Windows authentication or both authentication methods, which is
known as mixed mode.
Another method to check which authentication
modes are set up is to use TSQL code. The code in
Listing 1 displays the Authentication mode setup

SELECT CASE SERVERPROPERTY('IsIntegratedSecurityOnly’)

WHEN 1 THEN 'Windows Authentication Only’
WHEN 0 THEN 'Windows and SQL Server Authentication’
END as [Authentication Mode] ;
Authorization of login accounts to
access a database
To authorize access to database in SQL Server, one can grant permissions to
users or roles. Here are a few steps to do so:
a. Using SSMS (SQL Server Management Studio)
 Login to SSMS
 In Object explorer, expand the database folder
 Select the specific database you want to authorize access for
 Navigate to security and users’ folders
 Right click on the users to whom you want to grant or revoke permissions
 Choose properties
 In the user mapping section, tick the checkboxes for the desired permissions
(e.g. SELECT, INSERT, UPDATE, DELETE etc.) for the user.
b. Using Transact SQL
You can you use the keyword “grant” to grant permissions directly. Follow the syntax
below:
GRANT <permission> TO <user> [with grant option]
You can you use the keyword “revoke” to refuse/block permissions directly. Follow
the syntax below:
REVOKE <permission> ON TABLENAME TO <user>
One can equally revoke a user from accessing a particular database, to do that,
you need to first use the database in question and the write the command:
REVOKE CONNECT FROM username;
3. Authorization of users to access
objects
 a. Schema-Level Permissions: By granting permissions at the
schema level, you can provide access to all objects within that schema,
reducing the need to grant permissions individually.
 b. Database-Level Permissions: These permissions allow users or
roles to perform actions across the entire database, such as creating
tables, views, stored procedures, or managing security settings.
 c. Using Roles for Authorization: Roles provide a convenient way to
manage permissions for multiple users or groups. Instead of granting
permissions individually to each user, you can assign permissions to
roles and then add users to those roles
Example 1: Granting Object-Level Permissions
Suppose we have a database named "SampleDB" with a table called "Employees".
We want to grant SELECT, INSERT, and UPDATE permissions to a user named
"User1“.

• Granting permissions:
USE SampleDB;
GRANT SELECT, INSERT, UPDATE ON Employees TO User1;
Example 2: Granting Schema-Level Permissions
Assume we have a schema named "Sales" in the "SampleDB" database, containing
multiple tables. We want to grant SELECT and INSERT permissions to a user named
"User2“

• Granting permissions:
USE SampleDB;
GRANT SELECT, INSERT ON SCHEMA::Sales TO User2;
Example 3: Granting Database-Level Permissions
Suppose we want to grant CREATE PROCEDURE permission at the database level to a
user named "User3".

• Granting permissions:
USE SampleDB;
GRANT CREATE PROCEDURE TO User3;

Example 4: Using Roles for Authorization

Let's create a role named "SalesTeam" and grant SELECT permission on the "Orders"
table to the role. We will then add users "User4" and "User5" to the "SalesTeam" role.

• Creating the role and granting permissions:

USE SampleDB;
CREATE ROLE SalesTeam;
GRANT SELECT ON Sales.Orders TO SalesTeam;

• Adding users to the role:

USE SampleDB;
EXEC sp_addrolemember 'SalesTeam', 'User4’;
EXEC sp_addrolemember 'SalesTeam', 'User5';
4. Authorization between servers
Managing authorization between SQL Server servers involves controlling
access and permissions for various entities
 Changing Ownership with ALTER AUTHORIZATION: The ALTER
AUTHORIZATION statement allows you to change the ownership of
different securable entities within SQL Server. These entities can include
objects like tables, views, stored procedures, and more.
 The syntax for ALTER AUTHORIZATION syntax varies based on the entity
type and context( SQL Server, SQL Database, Azure Synapse Analytics,
or Parallel Data Warehouse).
so this is the syntax in the SQL server;
ALTER AUTHORIZATION ON [class_type::] entity_name TO
{ principal_name | SCHEMA OWNER };
<class_type> represents the type of securable (e.g., OBJECT, ASSEMBLY,
DATABASE).
entity_name refers to the specific entity (e.g., table, view, schema)
Practical example
use master;
/*created the login at the server level*/
CREATE LOGIN NewLogin1 with password = N'passw0rd'
must_change, check_expiration = on, check_policy=off;
use SE3;
/*creating the user at the database level*/
CREATE USER DONFACK for login NewLogin1
/*Now we need to add the user to the 'db_owner' role to have the required
permissions*/
ALTER ROLE db_owner ADD MEMBER DONFACK;
USE master;
ALTER AUTHORIZATION ON DATABASE::SE3 TO guest;
5. Permissions of users to access code
 User permissions, part of the overall user management process, are
access granted to users to specific resources such as files, applications,
networks, or devices.
 A user permission can also specify the type of access—for example, a
user might be allowed to read data without modifying it (read only) or
be allowed to read and write data, specific functions a user can access.
 User permission is tightly related to two concepts that are
Authentication and Authorization.
 User authentication involves verifying a user’s identity before allowing
them to access a system or application.
 User authorization is the process of determining which resources users
are allowed to access.
 Practical example follows
Create a Code Object:
USE YourDatabaseName;
CREATE PROCEDURE dbo.GetCustomer
AS
BEGIN SELECT * FROM Customers;
END

Create a User:
USE YourDatabaseName;
CREATE USER YourUserName ;
FOR LOGIN YourLoginName;

Grant Permissions:
USE YourDatabaseName;
GRANT EXECUTE ON dbo.GetCustomer TO YourUserName;

Test the Permissions:

USE YourDatabaseName;
EXECUTE AS LOGIN = 'YourLoginName’;
EXEC dbo.GetCustomer;
REVERT; (Revert back to the original login context)
Permission Types:
- EXECUTE: Grants permission to execute a stored procedure, function, or trigger.
- VIEW DEFINITION: Grants permission to view the definition of a code object (e.g.,
stored procedure, function, view)

Granting Permissions to Roles:

USE YourDatabaseName;
CREATE ROLE YourRoleName;
GRANT EXECUTE ON dbo.GetCustomer TO YourRoleName;
EXEC sp_addrolemember 'YourRoleName', 'YourUserName’;

Revoking Permissions:
USE YourDatabaseName;
REVOKE EXECUTE ON dbo.GetCustomer TO YourUserName;

Server-Level Permissions:
Examples include CREATE PROCEDURE, ALTER ANY PROCEDURE, VIEW ANY
DEFINITION, etc.