22.5  应用程序角色

应用程序角色与数据库角色和服务器角色有些不同。的确，由于对它们都使用角色这一术语，这很容易让人觉得它们比较相近——但其实不是这样。

实际上，应用程序角色更像是用户的安全性别名。应用程序角色允许定义一个访问列表（由数据库单独的权限或分组构成）。另外，由于应用程序角色有其自身的密码，这让它们与用户有些类似。尽管如此，应用程序角色与用户登录名是不同的，因为应用程序角色不能那样“登录”——用户账户必须先登录，然后，他（或她）可以激活应用程序角色。

那么，我们为了什么而需要应用程序角色呢？为了应用程序——还有什么？你将经常遇到这样的情形，希望用户根据他（或她）在什么上下文中访问数据库而拥有一组不同的权限。使用应用程序角色，你能够实现这样的事情：只授予用户到数据库的只读访问权限（只能执行SELECT语句），但是，当用户在应用程序的范围内访问数据库时，还是会允许他们修改数据。

注意，应用程序角色是单向的。即是说，对于一个指定的连接，一旦确定已经激活应用程序角色，则对那个连接来说，无法再回到用户自己的安全性上下文。为了回到用户自己的安全上下文，他们必须终止这个连接，并再次登录。

应用程序角色的作用过程类似下面这样：

(1) 用户登录（很可能使用应用程序提供的登录窗口）；

(2) 验证登录，用户获得了他（或她）的访问权限；

(3) 应用程序执行名为sp_setapprole的系统存储过程，并提供角色名和密码；

(4) 验证应用程序角色，然后，连接被切换到应用程序角色的安全上下文（失去了用户拥有的所有权限——现在，他（或她）拥有的是应用程序角色的权限）；

(5) 在整个连接期间，用户将继续保持基于应用程序角色的访问权限，而非基于他（或她）个人登录名的访问权限——用户不能回到他或她自己的访问信息。

你只会想把应用程序角色作为真正的应用程序情形的一部分来使用，并且，你将直接在应用程序中构建设置应用程序角色的代码。另外，你也将需要把密码编译到应用程序中，或者把这一信息存储在某个本地文件中，以便在需要的时候进行访问。

22.5.1  创建应用程序角色

要创建应用程序角色，可以使用一个新的称为sp_addapprole的系统存储过程。该存储过程是另一个使用起来相当简单的存储过程，其语法如下：

sp_addapprole [@rolename =] <角色名>,

[@password =] <'密码'>

与本章中许多存储过程一样，其参数是一目了然的。因此，我们直接进入到它的使用，创建我们自己的应用程序角色：

就是这样快，我们已经创建了应用程序角色。

22.5.2  向应用程序角色添加许可权限

向应用程序角色中添加许可权限与向任何其他事物中添加许可权限一样。只需在使用用户登录ID或者常规的服务器或数据库角色的地方，把它们替换成应用程序角色的名字即可。

同样，我们马上进入到一个例子：

现在，应用程序角色在Region表上拥有了SELECT权限——到此为止，它还没有任何其他的权限。

22.5.3  使用应用程序角色

应用程序角色的使用是这样一个过程：调用系统存储过程（sp_setapprole），并提供应用程序角色的名字和相应的密码。其语法如下：

sp_setapprole [@rolename =] <角色名>,

[@password =] {Encrypt N'密码}|'密码'

[,[@encrypt =] '<加密选项>']

role name就是你想要激活的应用程序角色的名字。

password或者原样提供，或者使用ODBC encrypt函数进行加密处理。如果准备加密密码，那么，需要在Encrypt关键字之后，用引号引住密码，并在前面放置一个大写的N——这向SQL Server表明，正在处理的是Unicode字符串，并且应当被如此对待。注意，为加密参数使用的是花括号｛｝，而不是圆括号。如果不希望加密，则不必使用Encrypt关键字来提供密码。

仅当为密码参数选择了加密选项时，才需要使用encryption style（加密类型）。如果对密码进行了加密，那么以“ODBC”作为加密类型。

值得注意的是，只有在使用ODBC或OLE DB客户端时，才能使用加密选项。不能把DB-lib与加密一起使用。

接下来进入示例的讲述，我们从验证几件与TestAccount用户的状态有关的事情开始。本章到了这里（假设你逐一学习了所有的例子），TestAccount用户不能访问Region表，但是，能够访问EmployeeTerritories表。通过运行两个SELECT语句，可以验证这种状态：

从第一个SELECT语句中会得到一个错误，而第二个语句则会返回大约50行记录。

现在，激活我们前面创建的应用程序角色，使用TestAccount用户输入下面的代码：

执行完上面的语句后，会得到一个确认消息，告知你应用程序角色已经“激活”。

通过运行前面的两条SELECT语句进行测试——会发现原来能做的和不能做的事情完全反过来了。即是说，尽管TestAccount能够访问EmployeeTerritories，但在使用应用程序角色时，失去了这种访问权限。TestAccount对Regions表没有访问权限，但是，眼下，应用程序角色提供了这种访问权限。

对于当前的连接，无法终止应用程序角色，因此，你可以终止你的TestAccount连接。然后，使用Windows安全性为TestAccount创建一个新的连接。再次运行那两条SELECT语句，会发现恢复了以前的访问权限。

22.5.4  删除应用程序角色

当服务器上不再需要应用程序角色时，可以使用sp_dropapprole从系统中删除它。其语法如下：

sp_dropapprole [@rolename =] <角色名>

要从系统中删除我们的应用程序角色，只需发出下面的命令（从sa）：