| title | description | author | ms.author | ms.reviewer | ms.date | ms.service | ms.subservice | ms.topic | helpviewer_keywords | monikerRange | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Application Roles |
Use application roles to enable access to data only for those users who connect through a specific application in SQL Server. |
VanMSFT |
vanto |
pijocoder |
06/30/2023 |
sql |
security |
conceptual |
|
=azuresqldb-current||>=sql-server-2016||>=sql-server-linux-2017||=azuresqldb-mi-current |
[!INCLUDE SQL Server Azure SQL Database Azure SQL Managed Instance]
An application role is a database principal that enables an application to run with its own, user-like permissions. You can use application roles to enable access to specific data to only those users who connect through a particular application. Unlike database roles, application roles contain no members and are inactive by default. Application roles are enabled by using sp_setapprole, which requires a password. Because application roles are a database-level principal, they can access other databases only through permissions granted in those databases to guest. Therefore, any database in which guest has been disabled is inaccessible to application roles in other databases.
In [!INCLUDEssNoVersion], application roles can't access server-level metadata because they aren't associated with a server-level principal. To disable this restriction and thereby allow application roles to access server-level metadata, set the global trace flag 4616 using -T4616 or DBCC TRACEON (4616, -1). If you prefer to not enable this trace flag, you can use a certificate-signed stored procedure to allow application roles to view server state. For sample code, see this sample script on GitHub.
The following steps make up the process by which an application role switches security contexts:
-
A user executes a client application.
-
The client application connects to an instance of [!INCLUDEssNoVersion] as the user.
-
The application then executes the
sp_setapprolestored procedure with a password known only to the application. -
If the application role name and password are valid, the application role is enabled.
-
At this point, the connection loses the permissions of the user and assumes the permissions of the application role.
The permissions acquired through the application role remain in effect for the duration of the connection.
In earlier versions of [!INCLUDEssNoVersion], the only way for a user to reacquire its original security context after starting an application role is to disconnect and reconnect to [!INCLUDEssNoVersion]. Beginning with [!INCLUDEssVersion2005], sp_setapprole has an option that creates a cookie. The cookie contains context information before the application role is enabled. The sp_unsetapprole stored procedure then uses the cookie to revert the session to its original context. For information about this new option and an example, see sp_setapprole (Transact-SQL) and sp_unsetapprole (Transaction-SQL).
Important
The ODBC encrypt option is not supported by SqlClient. When you are transmitting confidential information over a network, use Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), or IPsec to encrypt the channel. If you must persist credentials in the client application, encrypt the credentials by using the crypto API functions. In [!INCLUDEssVersion2005] and later versions, the parameter password is stored as a one-way hash.
| Task | Type |
|---|---|
| Create an application role. | Create an Application Role and CREATE APPLICATION ROLE (Transact-SQL) |
| Alter an application role. | ALTER APPLICATION ROLE (Transact-SQL) |
| Delete an application role. | DROP APPLICATION ROLE (Transact-SQL) |
| Using an application role. | sp_setapprole (Transact-SQL) |