毕业设计（论文）-福富Web通用单点登陆企业解决方案.doc

福州大学 2004 届毕业生 毕业论文(设计) 题 目：福富福富 webweb 通用单点登陆企业解决方案通用单点登陆企业解决方案 姓 名： 学 号： 专 业： 软件工程 指导教师： 摘要：摘要： 当为了支持商业进程而沿伸 it 系 统时，用户和系统管理员为了完成工作， 面对着日益增长的复杂的各种接口（人机交互接口）。用户需要登录多个的系 统，而系统管理员则需要以同样的方式，维护 多个系统的用户账号。单点登陆 系统能集统一各个系统的认证和授权，解决用户和管理员的困扰，并大大提高 安全性。本文，利用 kerberos 思想和 ssl 技术，在 http 协议基础上建立有效 的的认证和授权机制，提出可行的 web 单点登陆平台解决方案。 abstractabstract： as it systems proliferate to support business processes, users and system administrators are faced with an increasingly complicated interface to accomplish their job functions. users typically have to sign-on to multiple system, and system administrators are faced with managing user accounts within each of the multiple systems to be accessed in a co-ordinated manner. sigle sign-on system gets the process of authentication and issuing permission together from each system in sso platform. this page shows a feasible solution of the process of the authentication and issuing permission for web sso with kerberos and ssl technology on http. 关键字：关键字： single sign-on（sso），kerberos，ssl，权限, permission 目录目录 第一章 单点登陆概 述 2 1. sso 概念以及由 来 2 2. sso 模型与传统模 型 2 3. sso 成熟产品及其应 用 5 4. sso 安全性特 征 6 第二章 web sso 系统需求分 析 6 1. 浅层需 求 6 2. 深层需 求 7 第三章 系统总体架构设 计 10 1. web sso 认证机制架构设 计 10 1.1. ssl、数字证书和 kerberos 简 介 10 1.2. 非依赖的安全的 web 认 证 14 1.2.1. 登陆流程初步分析描 述 14 1.2.2. 登陆认证架构设 计 15 1.2.3. 系统攻击环节分 析 18 2. web sso 权限控制架构设 计 19 2.1. 用户角色应用服务权限模 型 19 2.2. 应用服务权限接口模 型 20 第四章 web sso 系统概要设 计 21 1. web sso 认证概要设 计 21 2. web sso 应用服务概要设 计 23 2.1. 表现 层 23 2.2. 业务 层 24 2.3. 数据 层 27 2.4. 票据加 密 27 结束 语 27 致 谢 27 参考文 献 28 第一章第一章 单点登陆概述单点登陆概述 1.1. ssosso 概念以及由来概念以及由来 单点登陆，即 single sign-on（sso），也叫做单一登陆，简单的说，sso 技术是一种认证和授权机制，它允许用户只登录到系统上一次，而后授权访问 其它连接的系统，无需再进行登录。 随着信息技术和网络技术的发展，各种应用服务的不断普及，用户每天需 要登录到许多不同的信息系统，如网络、邮件、数据库、各种应用服务器等。 每个系统都要求用户遵循一定的安全策略，比如要求输入用户 id 和 口令。随 着用户需要登录系统的增多，出错的可能性就会增加，受到非法截获和破坏的 可能性也会增大，安全性就会相应降低。而如果用户忘记了口令，不能执行任 务，就需要请求管理员的帮助，并只能在重新获得口令之前等待，造成了系统 和安全管理资源的开销，降低了生产效率。为避免这种尴尬，牢记登录信息， 用户一般 会简化密码，或者在多个系统中使用相同的口令，或者创建一个口令 “列表“。如果你使用易于记忆的口令或将单个口令用于所有的账户的话，安全 专家将会摇着头说：“容易记忆”也意味着“容易猜译”。安全专家反对重复 使用口令，反对将口令写下来保存在攻击者可能找到它们的任何地方。他们强 调用户应当经常更改口令。 当 这些安全风险逐步反映出来，管理员增加一些新的安全措施的时候，这 些措施却在减少系统的可用性，并且会增大系统管理的复杂度。因此，在市场 上提出了这样的 需求：网络用户可以基于最初访问网络时的一次身份验证，对 所有被授权的网络资源进行无缝的访问。从而提高网络用户的工作效率，降低 网络操作的费用，并提高 网络的安全性。 2.2. ssosso 模型与传统模型模型与传统模型 传统的分布式系统是由多个部分组成的，这些组成分别承担着各自独立安 全的域的功能。这些组件，由相互关联的操作系统和应用程序来组成了单独的 平台。 各个组成承担独立的域，意味着当终端用户想和这些域进行交互的时候，必须 单独的通过各个域来证书和认证自己。如上图所示，终端用户在和主域开始交 互的时候，建立起一个会话。在上图中，这被称作主域登录（primary domain sign-on），这时用户要提交一个可以被主域信任的认证证书，最常见的就是用 户名和密码。主域的会话常常由终端用户所在的工作站的终端用户环境中具有 代表性的信息中，由运行的操作系统会话机制来产生。从主域会话机制，用户 可以从主域中调用其它域的服务，例如平台或者应用程序。 要调用次域的服务，一个终端用户又需要进行次域登录（secondary domain sign-on），这就在次域里进行需要进一步的用户认证。这样，终端用 户就必须为了请求每一个次域，而被各个次域的登录对话框牵着鼻子走。而次 域的会话也和主域类似的机制来产生。从整个的流程来看，这种方式需要在各 个域独立的运作，并且需要多个的用户账号来操作接口。 要调用次域的服务，一个终端用户需要进行 secondary domain sign- on（次域登录），这就在次域里进行需要进一步的用户认证。这样，终端用户 就必须为了请求每一个次域，而被各个次域的登录对话框牵着鼻子走。而次域 的会话也和主域类似的机制来产生。从整个的流程来看，这种方式需要在各个 域独立的运作，并且需要多个的用户账号来操作接口。 在安全方面，网络信息犯罪逐年上升。计算机安全机构与 fbi 的研究表明。在 调查的公司中，32%的公司向执法官员报告发生严重事件，较上一年翻一番；报 告遭受经济损失的公司，平均损失高达 1200 万元人民币。网络攻击日益频繁， 各公司都不得不采取有效措施，保护其信息资源，减少风险。在这种情况下， 各机构就需要根据受破坏可能性以及可能导致的损失程度，来评估预防措施的 成本。例如，根据 fbi/csi 的调查报告显示，最普遍的信息安全问题来自于病 毒感染，在能够确定损失数额的机构中，90%的危害是由病毒感染引起的，平均 损失数额约为 60 万元；约 65%的被调查者是因笔记本电脑系统被盗，每年由此 类事件所导致的平均损失约为 100 万元。但与电子盗窃或金融欺诈相比,上述问 题就是小巫见大巫了。例如,尽管窃取机密信息可能不象病毒感染或笔记本电脑 被盗普遍，但其危害性却更高,为每家受害公司所带来的平均经济损失高达 2500 万元;而金融欺诈所导致的平均损失则约为 2000 万元。虽然这些犯罪发生 的频率低于病毒感染或笔记本电脑被盗,但由此造成的经济损失却高出许多。 使用性和安全性两个方面，要求在企业中建立起统一的登录功能和账号的 统一管理。提供这样的统一和集成能够实实在在的有益于企业： 减少用户在各个域中登录上花费的时间，也包括登录失败所浪费的时 间。 通过让用户减少提交和记忆认证信息，来有效改善安全性。 在系统管理员添加和移除用户，以及修改用户操作权限上，大大提高 效率。 通过采用统一用户账号配置，包括更加一致的控制和移除个别用户访 问系统资源的权限，来增强系统的安全性。 3.3. ssosso 成熟产品及其应用成熟产品及其应用 目前市场上，已经存在又一些成熟的单点登陆产品，或者规范。以下就列 举两个具有代表性的产品，并且针对其特点进行简单的介绍。 microsoft .net passport microsoft 的.net passport 是我们最为常见的 sso 认证平台，msn 的用户 登录以及管理就是在此平台上进行的。使用.net passport 实施 sso 的的最大 缺点是，对原有的应用系统的集成存在较大难度，甚至需要对原有的应用系统 的做较大的改动，来符合.net passport 的认证接口。而且采用此体系的应用 系统，同时也必须构筑在 windows 平台服务器上。 安盟 securid 系统 这套系统是国内最为成熟的产品之一，此系统在认证时，安盟 securid 向 授权的员工登记发放令牌, 生成令牌码，令牌码随时间变化。每 60 秒就会生成 一个随机令牌码, 保护网络的安盟认证服务器能够验证这个变化的代码是否有 效。每个认证令牌都是唯一的。别人不能通过记录以前的令牌码来预测将来的 令牌码，结合令牌码用户必须提供其记忆的 pin,这样，如果某个用户提供了一 个正确的 pin+令牌码,就 可以高度确信该用户即是合法用户。这样的做法固然 有很强的安全性，但是令牌的领取，以及每次都要使用不同的令牌码，就给用 户造成使用上的不便。而系统在设 计上，对令牌码生成、时间的漂移、同步有 很高的要求，也就造成系统的在这方面的复杂程度。另外，它对旧系统的集成， 也存在缺陷。 4.4. ssosso 安全性特征安全性特征 次域在访问时，必须被强迫信任主域。 这就意味者，对主域的信任高于对次域的信任，凡经过主域认证的用户， 都将有权访问次域。进一步的，主域必须确定用户在次域的活动权限。 终端用户的身份和认证证书的正确性和合法性的判断。 在未认证的使用者请求次域上的服务时，必须保护好认证证书的安全 性。 当在主域和次域间传输认证标识时，认证标识必须受到保护，以防止 中途拦截进行偷窃、以及篡改导致的伪装攻击。 第二章第二章 webweb ssosso 系统需求分析系统需求分析 福富 web 单点登陆系统，简称 fs-sso，针对以上所说的特点，来提出需求 的。 1.1. 浅层需求浅层需求 名称：名称：登陆平台 描述描述 用户访问 appserver（应用服务器），因为没有访问权限，而转向 sso server 进行登陆，登陆系统以后获得访问 app server 的权限。 用户直接访问 sso server，进行登陆，然后根据需要，转向需要 的 app server。 每次登录都有一个登陆有效期，如果超时，此次登陆请求将不予以 接受，必须重新申请登录。（这点需求是在设计过程中增补的，它 可以有效的增加登录的安全性，后面的架构设计中，更可明显的反 映出它的必要性） 名称：名称：注册新用户 描述描述 注册的信息包括：用户名、密码以及邮箱、个人说明等个人信息 名称：名称：修改用户信息 描述描述 注册过的用户可以修改自己的信息。 名称：名称：激活用户 描述描述 管理员给新注册的用户，分配其所属的用户组，有权访问的应用， 以及操作、访问的权限，并激活这个账号（可以允许自动激活） 名称：名称：管理用户 描述描述 用户帐号的激活、停用，批量用户操作 名称：名称：管理接入平台的应用 描述描述 管理接入平台的列表、平台的信息 管理与此应用有关联的用户 名称：名称：管理角色 描述描述 管理角色层次、角色信息，配置角色所具有的权限 名称：名称：管理用户权限 描述描述 管理用户权限层次、权限信息 2.2. 深层需求深层需求 从表面上看，用户的需求十分的简单，但是从深层次分析，平台需要有许 多的潜在需求。 2.1. 安全性潜在需求 尽管登录到一个系统的过程很简单：输入用户身份名，然后再输入口令， 但是它实际上采取了多个动作。首先是认证，认证发生在系统验证登录的实体 （人或程序）是否是与这个用户身份相关的实体时，认证通常通过将口令与用 户的 id 匹配来实现。系统利用错误信息回答非授权请求，并通过允许访问来响 应授权的请求。实际的授权可以在认证后立即进行，使客户得到授权资源的清 单。授权也可以是交互式的，当用户试图访问不同资源时服务器拒绝或同意访 问这些资源。在使用 sso 时，管理员指定特定平台作为主认证域（即 sso 域） 来控制对所有域的访问。当用户登录到这个 sso 主域时，他提供在登录到任何 次级域时所需要的所有证明。然后主域负责为次级域完成对用户的认证。所以， 通过认证后，系统对用户授以 sso 域中的授权，当用户需要对其他的某个域进 行访问时，再授予用户在这个域中的权限。 下面就系统安全需求，进行详细分析。 安全威胁的实体是指任何对网络或网络设备造成损害的个人、对象或事件。 脆弱性是指网络系统存在的可能被威胁利用的缺陷。分析受到威胁后造成的影 响，主要包括：直接的损失和潜在的影响、数据破坏、丧失数据的完整性、资 源不可用、诋毁名誉。 安全威胁的来源是多方面的，主要可以分为：自然灾害和人为因素。对于 fs-sso 而 言，解决自然灾害的的方法是保证服务器的物理安全性，而对于人 为因素的则属于逻辑安全性的范畴。人为因素按照攻击的目的性，又可以划分 为恶意攻击和非恶意 攻击。非恶意威胁主要是由于用户的正常过失引起的数据 完整性问题。软件缺陷、数据输入错误和管理错误都属于此类别。恶意威胁包 括不满或怀有恶意的现有员工 和以前员工，或者不属于组织外的人员进行的攻 击。内部人员可能有特定的目标，通常对环境内的系统具有某种级别的合法访 问权限。员工是对公司计算机和应用程 序了如指掌的群体，包括了解哪些攻击 行为和漏洞可使组织遭受最大的损失。这种类型的攻击极难检测或进行保护。 恶意的内部人员可能有特定的目标，通常具有对 系统的合法访问权限。恶意的 内部人员攻击可侵袭计算机安全或应用程序的所有组件。由恶意内部人员煽动 的其他类型的安全犯罪包括贿赂或社交工程。社交工程是 哄骗人员透漏其密码 或某种形式的安全信息的过程。这些行为经常无法检测，因为审核记录不充分 或无法复查。 综上所述，可以看出，解决安全问题因素，主要在于，提高管理员和系统 用户的安全意识，其次才是系统本身的设计。（本文主要在于讨论平台的系统 解决方案，所以对前者就不做太多的阐述。）根据 microsoft 对于恶意威胁的 研究，将其分为：哄骗标识（非系统设计因素）、篡改数据、抵赖、信息泄漏、 拒绝服务和特权提升。对于 fs-sso 系统设计的安全性，可以提出以下几点要求： 1. 访问应用服务需要授权证书 2. 证书必须保证来自合法的客户端 3. 根据 2，客户端的合法性需要受到验证 4. 不能够依赖用户的主动行为来销毁颁发证书，证书必须能够自动过期。 5. 应该尽量的减少口令在网络间的传输，并且绝对不能以明文的方式来 传输用户口令。 6. 确保收到的证书是来自指定的合法用户，即证书必须能够防止他人偷 窃、修改、以及证书的重复使用。 7. 详细划分用户的权限，并且对传输过程中的权限的相关信息进行加密， 以防止权限恶意修改、恶意提升权限。 8. 要有完善的记录，记录用户的登陆、认证及其它操作，防止抵赖。 9. 对信息进行加密，至少关键信息必须加密，以防止信息泄漏。 10. 阻止恶意登陆请求，防止拒绝服务。 11. 另外，针对 sso 平台特点，在系统的健壮性上，必须做到当攻击者绕 过认证系统，而获得其中一个接入平台的授权时，其活动范围仅限于 这个域，其他域的安全性不受到影响。 2.2. 系统部署需求 考虑到 fs-sso 解决方案，不仅针对将要搭建在平台上的应用系统，还针对 原有旧系统的接入问题时，fs-sso 的部署问题就显得格外突出。 接 入单点登陆平台的旧的应用系统，原来就已经构筑了一套完整的用户权 限系统，不同的系统构造的权限系统又不尽相同。它接入平台后，并不适合使 用平台的权限系 统，只需要借助平台的登陆认证机制。因此平台的认证机制为 了部署的特性，还要能够和原来旧系统的登陆进行集成。最理想的状态是无逢 集成，即不需对旧系统的 登陆认证进行改造，只要屏蔽掉就可以了。 而对于在平台的构筑的新系统，对权限系统有不同的使用。因此，与普通 权限系统开发不同的是，sso 平台要提供一个灵活的权限系统接口给新系统调 用。这个接口要有较强的通用性，以适合各种系统的开发；又要有较强的安全 性，以防止信息泄漏和权限提高。 第三章第三章 系统总体架构设计系统总体架构设计 目前，在各种企业级的开发中，用户权限的管理模型和机制经过这几年的 发展，再结合目前的开发技术平台，已经趋于完善了。基本上，开发的产品中， 在理论上，都有固定的可靠的模型；在实现上，也可以做到按照功能来划分权 限。所以，sso 平台的设计，难点并不在于权限机制的实现，而在于 sso 平台 的认证机制，以及 sso 平台的接入方案。本章将从架构层面阐述 sso 的认证机 制的方案，以及实际方案实施的可行性和安全性。 1.1. webweb ssosso 认证机制架构设计认证机制架构设计 很显然，sso 的认证属于跨域的、第三方认证的方式，这就自然会联想到 ssl、数字证书和 kerberos。 1.1. ssl、数字证书和 kerberos 简介 ssl 全称为“secure sockets layer“（安全套接层），是一种用于网站安 全连接的协议（或技术）。所谓的安全连接有两个作用。首先是 ssl 可以提供 信息交互双方认证对方的身份标识。显而易见地，这对当你开始与对方交换机 密信息前确切了解对方身份是非常重要的。ssl 通过数字证书的技术实现使得 这一需求得以满足。另一个是它能够使数据以不可读的格式传输，以利于在不 可信网络（例如互联网）上的安全传输需要。这种不可读格式通常由加密技术 实现。 数字证书是一种能在完全开放系统，例如互联网（之所以说互联网是一个 开放系统，是因为我们无法控制其中的用户是谁），中准确标识某些主体（如 一个人或一个网站）的机制。一个数字证书包含的信息必须能鉴定用户身份， 确保用户就是其所持有证书中声明的用户。数字证书由 ca（certificate authorities）机构承认。ca 是被银行、政府和其它公共机构认可用于标识证 书所有者的第三方机构。除了唯一的标识信息外，数字证书还包含了证书所有 者的公共密钥。证书的弱点，应该提醒的是类似 verisign 之类的公共 ca 机构 并不总是可靠的。系统管理员经常犯的错误是过于信任 verisign 等的公共 ca 机构。例如，如果 verisign 发放一个证书说我是“某某某”，系统管理员很可 能就会相信“我是某某某”。不幸的是，对于用户的证书，公共 ca 机构可能不 象对网站数字证书那样重视和关心其准确性。 kerberos v5 是业界的标准网络身份验证协议（rfc1510、rfc1964），该 协议是在麻省理工学院起草的，旨在给计算机网络提供“身份验证“。kerberos 协议的基础是基于信任第三方，如同一个经纪人（broker）集中的进行用户认 证和发放电子身份凭证，它提供了在开放型网络中进行身份认证三的方法，认 证实体可以是用户或用户服务。这种认证不依赖宿主机的操作系统或主机的 ip 地址，不需要保证网络上所有主机的物理安全性，并且假定数据包在传输中可 被随机窃取篡改。 kerberos 协议具有以下的一些优势： 与授权机制相结合 实现了一次性签放的机制，并且签放的票据都有一个有效期； 支持双向的身份认证，既服务器可以通过身份认证确认客户方的身份， 而客户如果需要也可以反向认证服务方的身份； 支持分布式网络环境下的认证机制，通过交换“跨域密钥“来实现。 kerberos 的认证机制大致如下： 1. 用户从 kerberos 客户机提供他或者她的用户名和密码（只由用户和应用 共享的一个密码）。这个密码只用于在客户端程序内部的处理，它永远也 不会进入网络。通过网络传输的只有用户名。 2. 将用户名和密码交给 kerberos 客户机。由 kerberos 客户机负责建立与应 用进行安全通信的上下文。 3. kerberos 客户机请求 as(authentication server，认证服务器)发出一个 tgt（ticket-granting ticket，票据授权票）。一个 tgt 请求表示一个 安全会话。一个客户机可以在一个安全会话中建立多个子会话。tgt 请求 包含了发出请求的客户的用户名，但是不包括密码（共享的秘密）。 4. kerberos 客户机向 as 发送请求。 5. 当 as 收到 tgt 请求时，它从请求中提出用户名并从内部数据库中取出相 应的密码（共享的秘密）。然后 as 发布一个 tgt 并将 tgt 包装在回复消 息中。这个 tgt 包含一个纯文本部分和一个密码文本（加密的）部分。为 了加密 tgt 的密码部分，as 使用了由用户的密码生成的加密密钥。因此， 只有知道密码的用户才能解开加密的部分。tgt 的加密部分还包含一个加 密密钥，称为会话密钥。 6. as 向发出请求的 kerberos 客户机发送回复消息（包括 tgt）。 7. 收到 as 的回复后，kerberos 客户机从回复中取出 tgt 并解密 tgt 中加密 的部分。然后 kerberos 客户机发出一个服务票据请求。这个请求包含了 tgt 和一个称为鉴别码 (authenticator)的加密结构。客户机用从 tgt 提 取出的会话密钥加密鉴别码。鉴别码证明客户机掌握会话密钥。服务票据 请求还指定了应用服务器的名字。 8. 客户机向 tgs（ticket-granting sever，票据授权服务器）发送服务票 据请求。tgs，它是 kdc（key distribution center，密码分派中心）的 一部分。 9. 收到服务票据请求后，tgs 提取客户机向其请求服务票据的服务器的名称， 然后授予一个服务票据。服务票据与 tgt 没有很大差别。与 tgt 一样，服 务票据包含一个纯文本部分和一个密码文本（加密的）部分。tgs 用服务 器的密钥（一个用服务器的共享的密码生成的密钥）加密服务票据的密码 文本部分，这样只有那个服务器可以解密这个服务票据的密码文本部分。 tgs 在服务票据的密码文本部分中还加入了一个新的加密密钥。这个密钥 称为 子会话密钥。注意现在有两个密钥：会话密钥和子会话密钥。 10.授予了服务票据之后，tgs 将服务票据包装在一个响应消息中。这个响应 消息也包含一个密码文本部分，它是用会话密钥加密的。响应消息的密码 文本部分包含子会话密钥。 11.tgs 向客户机发送响应消息。 12. 收到 tgs 响应后，客户机用会话密钥解密密码文本部分，从而提取出子 会话密钥。客户机还提取服务票据。 13.然后客户机向应用服务器发出消息，并在消息中包装了服务票据。这个消 息请求服务器与客户机建立新的安全会话。 14.客户机向应用服务器发送消息。 15.应用服务器从请求中提取服务票据，解密它的密码文本部分，并提取子会 话密钥。这样客户机和服务器就都掌握这个密钥了。 16.应用服务器向客户机发送一个肯定应答。 17. 另外需要说明的是 tgt，中包含有一个时间戳。时间戳的作用是确保这次的服 务请求时最新的、尚未回复的请求，仅限制在短时间内的有效性，还可以有效 防止暴力破解的恶意攻击。 1.2. 非依赖的安全的 web 认证 非一类的安全 web 认证指示，这种方法完全不依赖主机的操作系统上的认 证机制，不依靠基于主机地址的信任方式，不需要主机在网络中具有物理安全 性，并且假设网络中的数据包可能被截获、修改和替换。为了实现非依赖的安 全的 web 认证，就必须采用 kerberos 机制。但是，由于认证是在 web 上进行的， 还必须考虑到 http 协议的特点对实施上的不便，来进行设计。 http 协议是无状态的，基于 http 的 web 是开放式的，这都使得客户端发 出的内容无法按照 kerberos 的要求进行加密，如果收到 kerberos 信息，也按 照指定的规则进行解密。一个 http 的客户端的可以实现的，只是信息的保存。 这些，都使得在 web 上的应用认证机制，需要对 kerberos 有较大的改动。 1.2.1. 登陆流程初步分析描述 根据上述分析的思想，可以初步确定出用户认证的流程，如图所示： 如上图所示，用户选择登陆的入口，可以选择 sso 服务器，也可以选择平 台中的一个应用服务。如果选择的是一个应用服务，发出访问请求后，应用服 务器，要进行授权检查。如果用户已经具有应用服务的访问授权，则响应用户 发出的请求。如果，用户尚未得到 app 的访问授权，则察看用户是否具有 sso 的授权。如果用户已经有了 sso 的授权，根据前面的分析，次域必须信任主域， 所以，次域将给访问者发放应用服务的访问授授权。如果，用户也没有 sso 的 授权，则次域将请求转交给 sso，从而用户的访问进入主域。进入主域后，sso 也将检查用户是否具有 sso 的授权。如果已经授权，则返回原来的次域，把 sso 授权交给应用服务。用户已经通过了 sso 的授权，但是尚未得到访问的应 用的授权，这种情况，可能发生在用户事先选择的访问入口是 sso，并通过 sso 的认证，或者当一个用户访问从已经授权的应用，转向另一应用服务，这个服 务尚未获得授权给用户。sso 的授权，是通过登陆来进行的，其登陆的方式， 与普通系统登陆无异：登陆成功将获得授权；登陆失败将拒绝进行授权。sso 授权后，如果用户的访问来自应用服务，则将用户转会这个应用服务。这时， 用户的到了 sso 的授权，按照前面所描述的步骤，用户就能够得到应用服务的 响应了。 从上述的登陆流程中，可以看出，应用必须具有识别授权和进行授权的能 力。原先的旧系统是不具备这样的功能的，因此，在原来的应用服务和用户之 间必须添加一个代理。代理的功能就是为原来的系统提供额外的受理事务的能 力，它将为旧系统起到，过滤请求、检查授权、请求转向（转到 sso）、分派 授权的作用。另外，用户对应用的访问，转向 sso 授权，再回到应用的三个步 骤，必须存在于同一个会话之中。这是因为，根据 kerberos 的认证机制，对于 陌生的的请求，即尚未建立会话的请求，as 将分派一个票据授权票，如果转向 是由服务（包括 sso 和应用服务）来进行的动作，根据 http 协议，这种行为将 视作新的会话，这个会话与客户端向服务发出的请求分别属于不同的会话，因 而票据授权票将永远无效。所以从转向 sso 和从 sso 回到应用服务的动作，必 须从服务向客户端发送指令，让客户端进行请求转向，而应用服务和客户端之 间的会话，与客户端和 sso 之间的会话必须是同步的。同样的，这种客户端的 转向，将使得服务回应的授权，也直接交由客户端，由客户端进行转交。 1.2.2. 登陆认证架构设计 单纯的 web 客户端是无法实现 kerberos 客户机的功能，因此在设计的时候， 不得不把 kerberos 的功能划分到 sso 和 agent（代理）上。在划分过程并非单 纯的移交，而必须保证交互的安全性。 agent 是用户控制服务的请求和响应的，所以它将起到 as 的作用，产生和 发布 tgt。此外一个 agent 代表的是一个服务，与服务交互的消息必定通过它。 所以，它所发布的 tgt，就代表次 tgt 的用户的访问请求是针对这个服务的。 sso 的功能是认证用户、授权用户，所以它的特点就相当于 tgs，对用户的身份 进行校验，发放服务票据（server ticket，st）。在 kerberos 中，从 tgs 产 生的 st，是交给 kerberos 客户机处理后，交给应用服务；在 fs-ss0 中，将由 客户端转交给通往应用服务必经之路上的 agent。对于不同的应用服务，就有 不同会话，也就可定有不同的 tgt 和 st，所以为了能让用户在不同的域（服务） 间无阻碍通行，不能依赖 tgt 和 st，因此就另外的票来维护会话间的交互。 web 客户端无法像 kerberos 客户端一样使用户填写的密码不进入网络，因 此，必须使用有效方式来保护进入网络的密码。虽然 ssl 的数字证书具有不可 靠性，但是用它来保护 client 和 sso 之间的数据是安全的，所以 client 和 sso 之间的通信必须采用 ssl。 通过分析，可以得出认证机制的流程是这样的： 1. web 客户端（client）向应用服务（app）发出请求。 2. 请求的消息被代理（agent）截获，代理判断其为未授权的的 client（client 请求的这个会话没有 st）。 3. agent 针对这个会话生成 tgt,tgt 的明文是会话标识，密文中包含会话密 钥（session key）、时间戳、发出请求的 client 的标识信息、请求的服 务的标识信息等，密文部分由 sso 和 agent 之间共享的密钥来加密。 4. agent 在本地保留一份未加密的 tgt，并向 client 发送 tgt。 5. client 将 tgt、用户名、密码通过 ssl 信道提交给 sso，要求登陆。ssl 信道将保证流入网络的用户密码不被泄漏。 6. sso 收到 tgt。tgt 的明文中的会话标识，讲用作与 client 和 sso 之间会 话的逻辑同步。解密 tgt 的密文，从中解出会话密钥，这样在 agent 和 sso 之间的逻辑同步的会话里就共享了这个会话密钥。同时，解出的客户 端标识，用于验证客户端身份；应用服务表示，用于从 sso 服务器上的库 中取出已经注册的应用服务的信息。 7. sso 将用户名和密码，与库中的用户信息进行比对，以判断是否允许用户 登陆。 8. sso 生成 mt（master ticket）。mt 表示用户已经在 sso 上登陆过，它可 以用来同步和衔接两个会话（client 和应用服务、client 和 sso）。当用 户从一个已授权的域（服务）转向一个未授权的（服务）时，只要向 sso 提交 mt 和这个应用服务的 tgt，就可以产生出这个服务的 st，这样也避 免了再次的登陆。mt 明文为 client 在 sso 的会话标识，密文包含有用户 在 sso 中的标识、使用期限（一个工作日），用户已经获得授权的应用服 务域列表（可能未进入任何应用服务域）。sso 生成一个子会话密钥，这 个子会话密钥用于加密 mt 的密文部分。 9. sso 生成 st。st 与 tgt 一样，包含明文和密文两部分。明文依然是 client 在应用服务的会话标识。密文部分包含启动服务必要的信息（例如 介入平台的旧应用的认证所需用户名和密码，或者用户的权限信息）。密 文使用会话密钥进行加密。 10.client 获得 mt，并转发 st 给应用服务（实际由 agent 接收）。 11.agent 收到 st。找到这个会话的 tgt，使用 tgt 中的会话密钥对 st 进行解 密，只有在这个会话中的应用才能解开。并且收到 st 的时间必须在 tgt 的有效期内，通常 tgt 的有效期非常的短（一般 2 分钟）。 12.agent 把服务请求交给应用。 13.应用服务响应请求。 1.2.3. 系统攻击环节分析 为 了测试设计的安全性，可模拟攻击者对系统进行攻击。在深层需求的描 述中提到的针对平台系统的安全威胁来源，有内部攻击者和外部攻击者。外部 攻击者，是指企 业外部不具有平台任何权限的人员。内部攻击者是实施解决方 案的企业内部的成员，或者是原来企业内部的成员。比较二者，显然内部攻击 者所处的环境条件、可利 用的攻击手段都较外部攻击者来得强。所以，假定以 一个内部攻击者的身份来对系统平台进行攻击。 不妨在初始的安全条件里假设，重要信息没有因为其它因素遭到泄漏，如 别人得知用户密码，用户电脑操作系统的不安全性；加密的算法是可靠的，即 不能在短时间破解。首先，攻击目标是三张票据和登陆信息的窃取。tgt 是短 时效的票据，攻击者必须在短时间内取得票据，这是可能的。但是如果要使用 tgt 获得 mt 和 st，还必须使用用户名和密码进行登陆。如果是他人的密码，根 据前面的假设是不可知的；如果盗用他人的 tgt，结合自己用户秘密进行登陆， 在 sso 的服务器上，sso 根据的是用户帐号密码来分配用户在应用服务上的权 限的，所以单纯的盗用 tgt 是没有意义的。mt 的流通是在 ssl 通道上进行的， 所以 mt 不会被盗用。st 盗用同样是没有意义的，因为收到的 st 要使用保存在 agent 上的 tgt 中的会话密码进行解密。现在，假设攻击者使用暴力破解了 st，取得 st 中的会话密钥，然后他使用自己的帐号进行登陆，登陆以后他又截 获了 st，将 st 解密，修改 st 中信息来提高权限，再把修改的 st 使用会话密 要进行加密，发给 agent，这种行为，理论上是可能的，但是所花费的时间将 会超过 tgt 有效期，既是发出了 st，st 也不会被接受。同样的 mt 的时效也不 宜太长，一个工作日的时效是合适的，这样就可以避免被破解后的重用。这也 说明，为了防止攻击者过的加密密码，sso 和 agent 之间使用公钥加密，以及 定期跟换密钥。 2.2. webweb ssosso 权限控制架构设计权限控制架构设计 高 级的权限模型是把权限与平台系统的功能资源相关联（而非物理资源）， 这种设计权限的分配通常被结合到各个模块，或者模块的积累中，所以对于接 入平台的旧系 统，平台不便也不必要对它的权限系统进行改造。但对于准备在 平台上搭建的新系统，则必须提供一个便捷、统一的模型，使得新系统即能方 便的建立起符合自己功 能需要的权限体系，又能够在 sso 平台中，对用户的权 限进行统一分配。 2.1. 用户角色应用服务权限模型 有别于一般的用户-角色-权限模型，用户-角色-应用服务权限模型中添加 了应用服务对象。从逻辑上分析，每个应用所需要的权限是不同的，即每种角 色在不同的应用上的权限是不同的。而 sso 是用于统一管理的平台，对于复杂 的权限和系统设计紧密结合，所以权限不适合集成到 sso 中。同时应用服务要 在 sso 留有信息，就必须在 sso 上加入应用服务对象（实际上应用服务在 sso 上注册的信息中就包含所有权限的信息）。 管理员在分配权限的时候，将应用的权限分配给角色，角色分配给用户。 在用户通过登陆认证以后，sso 根据用户的信息，分配给用户具备访问权限的 应用服务，在每次用户进入这个服务时，sso 再把权限的列表提交给应用服务， 这时用户才真正取得操作的权限。 为了能够更加细致、方便的管理权限和角色，角色和权限被设计为具有继 承的特性。也就是说，角色和角色可以有树状层次关系，处于父结点的角色包 含有子节点角色具有的权限。而权限的结构也和角色的结构类似。 sso 系统，相当于整个平台中的一个特殊的应用服务，所以对于这个应用服务 也要有授权，它的授权有 mt 来控制。 2.2. 应用服务权限接口模型 当用户获得 st 以后将 st 交给 agent，并通过 agent 的校验。st 中还包括了权 限的标识的列表。这些标识交给应用服务后，应用服务就可以限制用户的操作。 通过上面描述的树状权限结构，可以把一类的权限归并于一个权限集下， 这样可以大大的减少 st 中的数据量。这样权限实际上又被分为，与操作直接关 联的基本权限，和由多个权限组合而成的组合权限。 由于基本权权限与设计直接相关，所以基本权限权限的数量和代表的操作 是不会变动的；组合权限虽然不会经常发生变动，但是还是会有变化。因此， sso 和应用服务之间的组合权限的结构需要同步。 对于权限的管理，必须先进入某个应用服务的域，即具有这个应用服务的 域的权限管理。这时，mt 可以发挥其对用户所在的应用服务的域的监控，用户 未进入应用服务的域中（除 sso 应用服务域外），即使具有管理权限的能力， 也不能对这个域的权限进行管理。 第四章第四章 webweb s