在 SQL Server 中创建应用程序角色

应用程序角色可提供对应用程序（而不是数据库角色或用户）分配权限的方法。 用户可以连接到数据库、激活应用程序角色以及采用授予应用程序的权限。 授予应用程序角色的权限在连接期间有效。

安全说明

当客户端应用程序在连接字符串中提供应用程序角色名称和密码时，可激活应用程序角色。 因为密码必须存储在客户端计算机上，所以这些角色在二层应用程序上导致一个安全漏洞。 在三层应用程序中，您可以存储密码，以便其他应用程序用户将无法对其进行访问。

应用程序角色功能

---

应用程序角色具有以下功能：

· 与数据库角色不同，应用程序角色不包含成员。

· 当客户端应用程序向 sp_setapprole 系统存储过程提供应用程序角色名称和密码时，可激活应用程序角色。

· 密码必须存储在客户端计算机上，并且在运行时提供；应用程序角色无法从 SQL Server 内激活。

· 密码不加密。 从 SQL Server 2005 开始，参数密码作为单向散列存储。

· 一旦激活，通过应用程序角色获取的权限在连接期间保持有效。

· 在 SQL Server 2000 中，无法将执行上下文切换回原始调用方。 因此，您必须关闭连接池才能使用应用程序角色。 有关更多信息，请参见 SQL Server 连接池 (ADO.NET)。

· 应用程序角色继承授予 public 角色的权限。

· 如果固定服务器角色 sysadmin 的成员激活某一应用程序角色，则安全上下文在连接期间切换为应用程序角色的上下文。

· 如果您在具有应用程序角色的数据库中创建 guest 帐户，则不必为该应用程序角色或调用它的任何登录名创建数据库用户帐户。 只有当在另一个数据库中存在 guest 帐户时，应用程序才能直接访问另一数据库。

· 返回登录名的内置函数（如 SYSTEM_USER）返回调用应用程序角色的登录名。 返回数据库用户名的内置函数将返回应用程序角色的名称。

最小特权原则

仅当密码遭泄漏时，应用程序角色才被授予必要的权限。 在使用应用程序角色的任何数据库中，应撤消对 public 角色的权限。 在不希望应用程序角色的调用方具有访问权限的任何数据库中，禁用 guest 帐户。

应用程序角色增强

从 SQL Server 2005 版本开始，执行上下文可在激活应用程序角色后切换回原始调用方，而不必禁用连接池。 sp_setapprole 过程具有一个创建 Cookie 的新选项，Cookie 包含有关调用方的上下文信息。 您可以通过调用 sp_unsetapprole 过程来还原会话，并向其传递 Cookie。

应用程序角色替代项

---

应用程序角色依赖于密码的安全性，而密码具有潜在的安全漏洞。 密码被嵌入应用程序代码或保存在磁盘上就有可能泄露。

对于 SQL Server 2005 或更高版本，您可能需要考虑下列其他选择。

· 使用通过 EXECUTE AS 语句及其 NO REVERT 和 WITH COOKIE 字句切换的上下文。 您可以在未映射为登录名的数据库中创建用户帐户。 然后，向此帐户分配权限。 对于很少登录的用户使用 EXECUTE AS 比较安全，因为它基于权限，而不基于密码。 有关更多信息，请参见在 SQL Server 中使用模拟来自定义权限 (ADO.NET)。

· 使用证书对存储过程进行签名，并仅授予执行这些过程的权限。 有关更多信息，请参见在 SQL Server 中为存储过程签名 (ADO.NET)。

以上内容转自：http://msdn.microsoft.com/zh-cn/library/bb669062.aspx