身份管理数据建模

　　构建身份管理数据模型可以很简单，也可以很复杂。最简单的模型是一个包含应用程序 ACL 的表。遗憾的是，该模型仅适用于基本 HTTP/HTTPS 身份验证。

　　实现 Cookie 和会话身份验证的最简单方法至少需要两个表。一个表包含 ACL，另一个表包含会话数据。下面描述了一个基本模型：

图 1 基本身份验证数据模型

　　更有效的身份验证解决方案应该支持捕获和挖掘用户交互。这些不同于为单个事件(如鼠标单击)调用的 Web 页面列表。图 2 显示了一个可以捕获用户导航、成功登录以及失败登录的数据模型。在本文的示例中，该数据模型由 create_identity_db.sql 脚本创建(参见示例代码 zip 文件)。

图 2 详细的身份验证数据模型

　　较大的模型可让您根据对模块的运行时调用来跟踪已定义模块的版本。实际参数映射到目录项，如 Amazon.com 上的书籍。还添加了访问日志，以跟踪单个会话期间进行的多个连接。实现模型的具体细节视您的目标而异。图 2 还显示了一个支持目录订单应用程序中的版本控制的示例模型。目前，示例代码只能尝试捕获无效日志，ACCESS_LOG 表已重新命名，以反映与 INVALID_SESSION 表的差异。

　　身份验证过程模型

　　基本 HTTP/HTTPS 身份验证通过在领域中建立浏览器的凭证来实现。浏览器可以同时支持多个领域。领域在 XHTML 文档的头中设置。它们可以在表单中手动编写，也可以在 httpd.conf 文件的 AuthName 指令中设置。领域充当受保护服务器区域的卫士，可应用于一个或多个受保护的服务器区域。基本 HTTP/HTTPS 身份验证的一个优势在于，您不必编写登录或注销程序。浏览器提供登录表单，您通过关闭所有打开的浏览器窗口来注销。

　　基本 HTTP/HTTPS 身份验证方法的一个主要缺点是，您必须关闭所有的浏览器窗口才能停止活动的领域授权。这意味着，如果用户经过了验证，但在离开终端时浏览器仍然处于打开状态，其他人就可以通过劫持身份来获取机密数据。

　　Cookie 和会话身份验证通过根据 ACL 检查用户凭证来实现。如果 ACL 存储在一个文件中，则意味着需要读取该文件，并将用户名和口令的名称/值对与已提交的明文用户名和加密口令进行比较。

　　如果 ACL 存储在数据库中，则意味着最初登录和后续连接时需要执行不同的身份验证。最初登录时，您将连接到数据库，并从数据库表中读取用户名和加密口令值;然后，将结果与已提交的明文用户名和加密口令进行比较。执行后续 Web 请求时，您将连接到数据库，读取会话 ID，然后将结果与已提交的会话 ID 进行比较。与基本 HTTP/HTTPS 身份验证不同，在 Web 浏览器打开的情况下，您也可以成功注销。

　　尽管会话 ID 是潜在的安全风险(由于会话劫持)，但通过合理的预防措施可将该风险降至最低。通过将登录页面实现为 PHP 脚本(而非简单的文本 XHTML 表单)，可以消除最大的安全隐患。示例 Cookie 和会话代码演示了这个方法。它可以确保共享计算机上的第二个用户不会利用先前的凭证登录。实现细节在下面的“Cookie 和会话身份验证模型”部分中说明。