单一登录 Web 应用程序的企业级安全系统

单一登录 Web 应用程序的企业级安全系统 发布日期 : 8/17/2004 | 更新日期 : 8/17/2004

Paul D. Sheriff PDSA,Inc.

适用范围： Microsoft ASP.NET

摘要：揭示能够以单一登录的方式登录多个 Web 应用程序的技术。本文还提供了示例代码，使您能够在完全使用单一登录的情况下创建强大的企业安全系统方面有一个良好的开端。

Download the code samples for this article（英文）。

本页内容

引言 单一登录解决方案概述 类和页面 表 AppLauncher Web 应用程序 Apps 类 在 Web 应用程序中检索令牌 增强您的单一登录系统 安装示例 结论 参考资料

引言

如果您的公司在运转方式上与其他绝大多数公司相同，那么您可能拥有许多用于支持公司业务的 Web 应用程序。绝大多数这种类型的应用程序需要采取安全措施，因为您肯定不希望用户随心所欲地进入任何 Web 应用程序。例如，只允许某些用户进入执行摘要决策支持系统，而其他用户则应只允许进入客户信息系统。有可能还有一些使用这些系统的外部用户，他们并不是您的 Microsoft Windows 域用户。可以通过安全机制强制每个用户登录系统，从而对此进行控制。但这样做的问题在于，访问不同系统时，每个系统都会不断地要求用户登录。对于仅仅具有五个 Web 应用程序的公司，如果某用户被允许访问其中的每一个程序，该用户会因为频繁地登录和注销而厌烦不已。所以必须找到一个更好的办法。

在阅读本文后，您将了解一种在企业中应用单一登录解决方案的方法。公司的内部用户可以使用 Windows 身份验证访问应用程序，而外部用户将被强制进行登录（参见图 1）。

本文所讨论的主题

单一登录 Web 应用程序

• 生成单一登录令牌

• 将用户映射至应用程序

• 基于窗体的身份验证

• Windows 中集成的身份验证

单一登录解决方案概述

图 1 所示为内部用户和外部用户在登录到位于一个公司的 Intranet 上的网站时所执行的一系列步骤。在 50,000 英尺的级别上，这个系统仅有四个组件：通过 Windows 身份验证的网站、Active Directory、一个数据库服务器和一个或多个基于窗体进行身份验证的网站。

Intranet 解决方案

在图 1 的左上角可以看到内部用户使用浏览器浏览到特定的网站（第 1 步）。这个网站验证（第 2 步）用户的 Windows 凭据（通过 Active Directory）。如果用户是有效的 Windows 用户，则允许其进入该站点。通过身份验证后，将检索用户的标识，并调用包含指定用户能够运行的应用程序列表的数据库表（第 3 步）。这些应用程序将显示在 DataGrid 中，以供用户选择。

用户单击希望运行的应用程序后，将生成一个唯一的、只能使用一次的令牌（第 4 步）。此令牌和用户标识将被存储在另一个数据库表中。然后此令牌被传递给用户要运行的 Web 应用程序中的一个特定页面（通过查询行）。此特殊页面从查询行读取该令牌，然后验证在数据库表中是否存在此令牌（第 5 步）。如果令牌存在，它将在数据库中检索登录 ID，然后删除存储此令牌的记录。此操作能够防止其他人再次使用此令牌并将登录 ID 发送回 Web 应用程序。

在了解了 Web 应用程序中的用户标识后，您需要生成一个 ASP.NET 窗体身份验证票据，因为在 Intranet 中，所有的 Web 应用程序都将使用基于窗体的身份验证。此票据将被正在浏览站点中所有的安全页面的用户所使用。

Extranet 解决方案

想要访问 Web 应用程序的外部用户（您所在域之外的用户）将被定向到与内部用户不同的起始页面（参见图 2）。内部用户和外部用户被定向到的 Web 应用程序采取了基于窗体的身份验证的安全措施。当外部用户试图打开此 Web 应用程序中的任何页面时，他们将被自动重定向至登录页面。此登录页面与对内部用户进行身份验证的页面不同。用户必须输入其凭据，然后系统将调用同一个数据库，以确定该用户对此应用程序是否有效。如果有效，则将为此用户会话生成正常的基于窗体的身份验证 cookie。

类和页面

您需要创建若干类和 Web 页面以支持企业级安全系统。图 2 显示了需要为此系统编写的每个类和 Web 页。本文稍后将讨论此图所显示的每个类。在此图之后，列出了每个类的说明信息以及您的系统中的 Web 页面主要功能。

Apps 类

此类用于检索指定用户的应用程序列表。它还将生成一个新令牌、根据给定的令牌检索用户的标识信息以及删除令牌。

AppToken 类

此类包含从 Apps 类的 VerifyLoginToken 方法返回令牌信息时所需的四个属性。表 2 说明了此类包含的四个属性。

AppUserRoles 类

此类用于检索试图登录应用程序的用户的信息。其中的一个方法根据给定的登录 ID 和应用程序键值检查登录是否有效。另一个方法返回给定用户的角色集。还有一个方法根据登录 ID 和应用程序键值返回 esUser 表的主键。

AppLauncher 应用程序中的 Default.aspx

此 Web 页类将检索通过了 IIS 身份验证的 Windows 用户，并返回允许这些用户访问的应用程序的列表。它将在 DataGrid 中显示此列表（图 3），并允许用户单击其中特定的应用程序。用户单击应用程序后，此页将生成一个新令牌，并将此令牌和用户 ID 存储到 esAppToken 表，然后调用此应用程序将令牌传递给该 Web 应用程序中的 AppLogin.aspx 页。

每个网站中的 AppLogin.aspx

只能从应用程序启动器调用此 Web 页类。若有任何其他的应用程序试图调用此页，它会将用户重定向至网站的 Default.aspx 页。因为每个 Web 应用程序都使用基于窗体的身份验证，所以此操作将强制 ASP.NET 将用户重定向至站点中的 Login.aspx 页。

如果使用令牌从应用程序启动器站点调用此页，那么此页将调用 Apps 类中的方法，以验证此令牌是否有效。如果令牌有效，则 Apps 类将返回一个 AppToken 对象，以便此页能够使用此对象中的信息创建基于窗体的身份验证的用户。

每个网站中的 Login.aspx

这是常规的 Web 登录页面，它要求用户输入凭据，并在数据库中检查这些凭据，以确保是有效用户；此外，如果是有效用户，则还将创建身份验证票据，并在用户进入站点时，重定向至用户请求的页面。

每个网站中的 Default.aspx

这是每个网站的主登陆页面。只有通过了 AppLogin 或 Login Web 页面的身份验证的用户才能够浏览此页以及站点中所有其他页。

表

您还需要在数据库中创建若干表，用来支持此单一登录企业级安全系统。本文中的表所包含的字段不多，但就所述内容而言，已经足够。图 4 显示了需要在数据库中创建的每个表之间的关系。在图 4 之后，会看到这些表的列表，以及本解决方案中使用的每个表的说明信息。

esApps

此表包含企业中所有 Web 应用程序的列表。除应用程序的名称以外，表中还包含应用程序的详细说明信息以及应用程序的 URL。URL 是完整形式的 URL，并且应以 AppLogin.aspx 页结尾。应用程序启动器中的 default.aspx 页将负责在重定向至 Web 应用程序前向 URL 中添加字符串 “Token=<GeneratedToken>”。

esUsers

此表列出可以使用应用程序的所有用户。您需要为所有内部用户复制您的用户域登录 ID。您可能还希望为外部用户添加密码字段。

esAppsUsers

此表将 esUsers 表中的用户与 esApps 表中他们能够运行的应用程序关联起来。表中的数据只有 esUsers 表和 esApps 表的外键。

esAppRoles

此表包含每个应用程序的角色集。例如，一个应用程序可能包含“Admin”和“User”角色，而其他应用程序则可能包含“User”和“Supervisor”规则。

esAppUsersRoles

此表包含应用程序中每个用户的每一个角色的列表。在应用程序“HR”中，用户“Joe”可能是“Supervisor”，但在应用程序“Payroll”中，则可能是“Admin”和“User”。

esAppToken

esAppToken 包含由登录门户应用程序生成并传递给单个 Web 应用程序的令牌。这些记录在通常情况下应只存在两秒（或更短的时间），因为正被调用的 Web 应用程序在从此表中收集信息之后，会立即删除此令牌。这样可以防止他人再次使用此令牌。

AppLauncher Web 应用程序

应用程序启动器解决方案（ 图 9）由通过 Windows 身份验证的站点和类库项目组成。此通过 Windows 身份验证的站点将直接读取线程中的用户域 ID，并利用此用户域 ID 在用户表中查找用户。我们看一下显示用户能够运行的应用程序的 Web 页。

AppLauncherxx 中的 Default.aspx

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!