Authorizing Users to Access Resources

Objectives
After completing this lesson, you will be able to:
Authorize user access to objects
Authorize users to execute code
Configure permissions at the schema level

SQL Server has a fine-grained security model that allows you to grant the minimum permissions to users that will allow them
to do their work. In particular, permissions can be granted at the column-level, not just at the table and view level.

What Are Principals?

Principals are entities that can request and can be granted access to SQL Server resources.
Principals can be arranged in a hierarchy


At the Windows level, principals include users and groups. Local accounts are able to be used from servers, whether the
server is a member of a domain or not.

At the SQL Server level, logins can be created for users that are either not Windows users or for users that are part of non-
trusted Windows environments. Also at the SQL Server level, fixed server roles are a form of principal that contains other
principals.

At the database level, you have seen database users, fixed and user-defined database roles and application roles.

Every principal has a principal ID and a security identifier (SID).

What Are Securables?

Securables are the resources to which the SQL Server Database Engine authorization system regulates access. Some
securables can be contained within others, creating nested hierarchies called "scopes" that can themselves be secured. The
securable scopes are server, database, and schema.




GRANT and REVOKE
A user that has not been granted a permission is unable to perform the action related to the permission. For example, users
have no permission to SELECT data from tables that they do not own.
The GRANT command is used to assign permissions to database users. The REVOKE command is used to remove those
same permissions.

DENY

The DENY command allows you to deny a permission to a user that has been granted permission by membership of a
group or role that has permission. This is very similar to how deny permissions work in Windows. For a Windows example,
consider that you could decide that all members of the Salespeople group can access a Color printer, except Holly (who is a
member of Salespeople) because she causes problems with it. You grant access to the Salespeople group then deny
access to Holly.

You could grant SELECT permission on a table to every Salesperson but deny Holly access to that table.

REVOKE command is also used to remove a DENY, not just to remove a GRANT. This means that it could cause a user to
have access that they did not have before the REVOKE command was issued. For example, if you revoke the DENY
permission from Holly, she would then be able to access the table.



The permissions to access data that apply to tables and views are SELECT, INSERT, UPDATE, DELETE, and
REFERENCES.

OBJECT:: as a prefix, this prefix is optional. In the second example, the same GRANT is shown without the OBJECT:: prefix.

REFERENCES
The REFERENCES permission is necessary before a foreign key relationship can specify the object as a target, and is only
required if no other permissions exist on the object.


SELECT permission on the Marketing.Salesperson table is being granted to James but access to the entire table is not
being granted. Only permission to the SalespersonID and EmailAlias columns is permitted.

Holly is denied permission to SELECT from the Salesperson table but is then granted permission to SELECT specific
columns in the table. The result (probably an unexpected result) is that Holly would still be permitted to SELECT from those
columns in the table.




When a principal is granted a permission, it is also possible to grant the principal the right to re-grant the permission to other
principals.
In the first example on the slide, James is granted permission to update the Marketing.Salesperson table. In addition, James
is granted the right to grant this same permission to other users.

CASCADE
The challenge of the WITH GRANT option comes when you need to REVOKE or DENY the permission that was granted to
James with the WITH GRANT option. You do not know which other users James has already granted the permission to.
When revoking or denying a permission that has been granted, the CASCADE option revokes or denies the permissions
that James had granted as well.

Query the full list of server principals.
SELECT * FROM sys.server_principals;
GO
Query the full list of database principals.
SELECT * FROM sys.database_principals;
GO
Grant permission on table
GRANT SELECT ON dbo.tablename TO PLOGIN;
GO

GRANT SELECT ON dbo.tablename
(Column1, Column2)
TO PLogin;
GO


Authorizing Users to Execute Code


By default, users cannot execute stored procedures that you (or any user) create.
In the example, the database user Mod11User is being granted the permission to execute the stored procedure
Reports.GetProductColors.


User-defined functions (UDFs) also require permissions before they can be used.
Scalar UDFs return a single value. Users accessing these functions require EXECUTE permission on the UDF.
Table-valued UDFs (which are TVFs) return a table of results rather than a single value. Accessing a TVF requires
SELECT permission rather than EXECUTE permission, similar to the permissions on a table.

REFERENCES
REFERENCES permission is required for:
Functions that are used in CHECK constraints.
To calculate values for DEFAULT constraints.
To calculate values for computed columns.



Ownership chaining applies to stored procedures, views, and functions. The slide shows an example of how ownership
chaining applies to views or stored procedures.
1. John has no permissions on the table owned by Nupur.
2. Nupur creates a view or stored procedure that access the table and grants John permission to access the view or stored
procedure. Access is granted as Nupur is the owner of both the top level object (that is the view or stored procedure) and of
the underlying object (that is her table).
3. Nupur than creates a view or stored procedure that accesses a table that is owned by Tim. Even if Nupur has permission
to access the table, and grants John permission to use the view or stored procedure, John will be denied access. This is
because of the broken chain of ownership from the top level object to the underlying object.
4. However, if John is given permissions directly on the underlying table owned by Tim, he can then access the view or
stored procedure that Nupur created to access that table.

Grant EXECUTE on the stored procedure to PLogin.

GRANT EXECUTE ON Reports.GetProductColors
TO PLogin;
GO

Configuring Permissions at the Schema Level

Schemas are used as containers for objects such as tables, views, and stored procedures. Schemas can be particularly
helpful in providing a level of organization and structure when large numbers of objects are present in a database.



Schemas
In SQL Server, schemas are essentially used as containers for objects, somewhat like a folder is used to hold files at the
operating system level. Since their change of behavior in SQL Server 2005, schemas can be used to contain objects such
as tables, stored procedures, functions, types, views, etc. Schemas are created with the CREATE SCHEMA statement and
schemas form a part of the multi-part naming convention for objects. In SQL Server, an object is formally referred to by a
name of the form:
Server.Database.Schema.Object

Built-in Schemas
dbo and guest have been discussed in the last module. The sys and INFORMATION_SCHEMA schemas are reserved for
system objects. You cannot create objects in those schemas and you cannot drop those schemas.



Instead of assigning individual permissions on tables, views, and stored procedures, permissions can be granted at the
schema level.


In the first example on the slide, EXECUTE permission on the Marketing schema is granted to Mod11User. This means that
Mod11User could then execute all stored procedures and functions within the schema.
In the second example on the slide, SELECT permission on the DirectMarketing schema is granted to Mod11User. This
means that Mod11User could then select from all tables, views, and table-valued functions in the schema.