首页 > IT基础架构 > 网络安全 > 单一登录Web应用程序的企业级安全系统(转)
图 1:涵盖内部用户和外部用户的单一登录解决方案的示例 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 页面主要功能。
图 2:设计和开发单一登录解决方案只需要几个类和页面 Apps 类 此类用于检索指定用户的应用程序列表。它还将生成一个新令牌、根据给定的令牌检索用户的标识信息以及删除令牌。
AppToken 类 此类包含从 Apps 类的 VerifyLoginToken 方法返回令牌信息时所需的四个属性。表 2 说明了此类包含的四个属性。
AppUserRoles 类 此类用于检索试图登录应用程序的用户的信息。其中的一个方法根据给定的登录 ID 和应用程序键值检查登录是否有效。另一个方法返回给定用户的角色集。还有一个方法根据登录 ID 和应用程序键值返回 esUser 表的主键。 AppLauncher 应用程序中的 Default.aspx 此 Web 页类将检索通过了 IIS 身份验证的 Windows 用户,并返回允许这些用户访问的应用程序的列表。它将在 DataGrid 中显示此列表(图 3),并允许用户单击其中特定的应用程序。用户单击应用程序后,此页将生成一个新令牌,并将此令牌和用户 ID 存储到 esAppToken 表,然后调用此应用程序将令牌传递给该 Web 应用程序中的 AppLogin.aspx 页。
图 3:应用程序启动器显示允许登录的用户运行的应用程序的列表 每个网站中的 AppLogin.aspx 只能从应用程序启动器调用此 Web 页类。若有任何其他的应用程序试图调用此页,它会将用户重定向至网站的 Default.aspx 页。因为每个 Web 应用程序都使用基于窗体的身份验证,所以此操作将强制 ASP.NET 将用户重定向至站点中的 Login.aspx 页。 如果使用令牌从应用程序启动器站点调用此页,那么此页将调用 Apps 类中的方法,以验证此令牌是否有效。如果令牌有效,则 Apps 类将返回一个 AppToken 对象,以便此页能够使用此对象中的信息创建基于窗体的身份验证的用户。 每个网站中的 Login.aspx 这是常规的 Web 登录页面,它要求用户输入凭据,并在数据库中检查这些凭据,以确保是有效用户;此外,如果是有效用户,则还将创建身份验证票据,并在用户进入站点时,重定向至用户请求的页面。 每个网站中的 Default.aspx 这是每个网站的主登陆页面。只有通过了 AppLogin 或 Login Web 页面的身份验证的用户才能够浏览此页以及站点中所有其他页。
表 您还需要在数据库中创建若干表,用来支持此单一登录企业级安全系统。本文中的表所包含的字段不多,但就所述内容而言,已经足够。图 4 显示了需要在数据库中创建的每个表之间的关系。在图 4 之后,会看到这些表的列表,以及本解决方案中使用的每个表的说明信息。
图 4:实现单一登录系统的完整角色所需的若干表 esApps 此表包含企业中所有 Web 应用程序的列表。除应用程序的名称以外,表中还包含应用程序的详细说明信息以及应用程序的 URL。URL 是完整形式的 URL,并且应以 AppLogin.aspx 页结尾。应用程序启动器中的 default.aspx 页将负责在重定向至 Web 应用程序前向 URL 中添加字符串 “Token=
图 5:esApps 表的示例数据 esUsers 此表列出可以使用应用程序的所有用户。您需要为所有内部用户复制您的用户域登录 ID。您可能还希望为外部用户添加密码字段。
图 6:esUsers 表的示例数据 esAppsUsers 此表将 esUsers 表中的用户与 esApps 表中他们能够运行的应用程序关联起来。表中的数据只有 esUsers 表和 esApps 表的外键。 esAppRoles 此表包含每个应用程序的角色集。例如,一个应用程序可能包含“Admin”和“User”角色,而其他应用程序则可能包含“User”和“Supervisor”规则。
图 7:esAppRoles 表的示例数据 esAppUsersRoles 此表包含应用程序中每个用户的每一个角色的列表。在应用程序“HR”中,用户“Joe”可能是“Supervisor”,但在应用程序“Payroll”中,则可能是“Admin”和“User”。 esAppToken esAppToken 包含由登录门户应用程序生成并传递给单个 Web 应用程序的令牌。这些记录在通常情况下应只存在两秒(或更短的时间),因为正被调用的 Web 应用程序在从此表中收集信息之后,会立即删除此令牌。这样可以防止他人再次使用此令牌。
图 8: esAppToken 表的示例数据 AppLauncher Web 应用程序 应用程序启动器解决方案(图 9)由通过 Windows 身份验证的站点和类库项目组成。此通过 Windows 身份验证的站点将直接读取线程中的用户域 ID,并利用此用户域 ID 在用户表中查找用户。我们看一下显示用户能够运行的应用程序的 Web 页。 图 9:AppLauncherxx 解决方案包含 AppLauncherxx 项目和对 AppLauncherDataxx 项目的引用 AppLauncherxx 中的 Default.aspx 应用程序启动器网站只需要一个 Web 页:即 default.aspx。此 Web 页从页面的 User 对象中读取用户的 Windows 登录 ID,并加载数据库中为此用户定义的应用程序列表。以下是加载 default.aspx 页面时调用的 Page_Load 事件过程的代码。 // C# private void Page_Load(object sender, System.EventArgs e) { // 显示用户名称 // 不带域前缀 lblLogin.Text = "Applications Available for: " + Apps.LoginIDNoDomain(User.Identity.Name); AppLoad(); } ' VB.NET Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load ' 显示用户名称 ' 不带域前缀 lblLogin.Text = "Applications Available for: " & _ Apps.LoginIDNoDomain(User.Identity.Name) AppLoad() End Sub 调用 Apps 类的静态方法 LoginIDNoDomain 是为了去除域前缀。如果登录 ID 为“Ken”的用户通过了名为“PDSA”的域的身份验证,那么 User.Identity.Name 属性将返回“PDSAKen”。而此方法则仅返回字符串“Ken”。 加载此用户能够运行的应用程序 AppLoad 方法使用 Apps 类的一个实例检索允许此用户运行的应用程序的 DataSet。本文后面的内容将显示 Apps 类中的 GetAppsByLoginID 方法。 // C# private void AppLoad() { Apps app