福州大学2004届毕业生
毕业论文(设计)
题 目：福富Web通用单点登陆企业解决方案
姓 名： 石 伟
学 号： 0500930
专 业： 软件工程
指导教师： 黄志华 赖金辉
2004年6月
摘要：
当为了支持商业进程而沿伸IT系统时，用户和系统管理员为了完成工作，面对着日益增长的复杂的各种接口（人机交互接口）。用户需要登录多个的系统，而系统管理员则需要以同样的方式，维护多个系统的用户账号。单点登陆系统能集统一各个系统的认证和授权，解决用户和管理员的困扰，并大大提高安全性。本文，利用Kerberos思想和SSL技术，在HTTP协议基础上建立有效的的认证和授权机制，提出可行的Web单点登陆平台解决方案。
Abstract：
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. SSO概念以及由来
单点登陆，即Single Sign-On（SSO），也叫做单一登陆，简单的说，SSO技术是一种认证和授权机制，它允许用户只登录到系统上一次，而后授权访问其它连接的系统，无需再进行登录。
随着信息技术和网络技术的发展，各种应用服务的不断普及，用户每天需要登录到许多不同的信息系统，如网络、邮件、数据库、各种应用服务器等。每个系统都要求用户遵循一定的安全策略，比如要求输入用户ID和口令。随着用户需要登录系统的增多，出错的可能性就会增加，受到非法截获和破坏的可能性也会增大，安全性就会相应降低。而如果用户忘记了口令，不能执行任务，就需要请求管理员的帮助，并只能在重新获得口令之前等待，造成了系统和安全管理资源的开销，降低了生产效率。为避免这种尴尬，牢记登录信息，用户一般会简化密码，或者在多个系统中使用相同的口令，或者创建一个口令"列表"。如果你使用易于记忆的口令或将单个口令用于所有的账户的话，安全专家将会摇着头说：“容易记忆”也意味着“容易猜译”。安全专家反对重复使用口令，反对将口令写下来保存在攻击者可能找到它们的任何地方。他们强调用户应当经常更改口令。
当这些安全风险逐步反映出来，管理员增加一些新的安全措施的时候，这些措施却在减少系统的可用性，并且会增大系统管理的复杂度。因此，在市场上提出了这样的需求：网络用户可以基于最初访问网络时的一次身份验证，对所有被授权的网络资源进行无缝的访问。从而提高网络用户的工作效率，降低网络操作的费用，并提高网络的安全性。
2. SSO模型与传统模型
传统的分布式系统是由多个部分组成的，这些组成分别承担着各自独立安全的域的功能。这些组件，由相互关联的操作系统和应用程序来组成了单独的平台。
各个组成承担独立的域，意味着当终端用户想和这些域进行交互的时候，必须单独的通过各个域来证书和认证自己。如上图所示，终端用户在和主域开始交互的时候，建立起一个会话。在上图中，这被称作主域登录（Primary Domain Sign-On），这时用户要提交一个可以被主域信任的认证证书，最常见的就是用户名和密码。主域的会话常常由终端用户所在的工作站的终端用户环境中具有代表性的信息中，由运行的操作系统会话机制来产生。从主域会话机制，用户可以从主域中调用其它域的服务，例如平台或者应用程序。
要调用次域的服务，一个终端用户又需要进行次域登录（Secondary Domain Sign-on），这就在次域里进行需要进一步的用户认证。这样，终端用户就必须为了请求每一个次域，而被各个次域的登录对话框牵着鼻子走。而次域的会话也和主域类似的机制来产生。从整个的流程来看，这种方式需要在各个域独立的运作，并且需要多个的用户账号来操作接口。
要调用次域的服务，一个终端用户需要进行Secondary Domain Sign-on（次域登录），这就在次域里进行需要进一步的用户认证。这样，终端用户就必须为了请求每一个次域，而被各个次域的登录对话框牵着鼻子走。而次域的会话也和主域类似的机制来产生。从整个的流程来看，这种方式需要在各个域独立的运作，并且需要多个的用户账号来操作接口。
在安全方面，网络信息犯罪逐年上升。计算机安全机构与FBI的研究表明。在调查的公司中，32%的公司向执法官员报告发生严重事件，较上一年翻一番；报告遭受经济损失的公司，平均损失高达1200万元人民币。网络攻击日益频繁，各公司都不得不采取有效措施，保护其信息资源，减少风险。在这种情况下，各机构就需要根据受破坏可能性以及可能导致的损失程度，来评估预防措施的成本。例如，根据FBI/CSI的调查报告显示，最普遍的信息安全问题来自于病毒感染，在能够确定损失数额的机构中，90%的危害是由病毒感染引起的，平均损失数额约为60万元；约65%的被调查者是因笔记本电脑系统被盗，每年由此类事件所导致的平均损失约为100万元。但与电子盗窃或金融欺诈相比,上述问题就是小巫见大巫了。例如,尽管窃取机密信息可能不象病毒感染或笔记本电脑被盗普遍，但其危害性却更高,为每家受害公司所带来的平均经济损失高达2500万元;而金融欺诈所导致的平均损失则约为2000万元。虽然这些犯罪发生的频率低于病毒感染或笔记本电脑被盗,但由此造成的经济损失却高出许多。
使用性和安全性两个方面，要求在企业中建立起统一的登录功能和账号的统一管理。提供这样的统一和集成能够实实在在的有益于企业：
l 减少用户在各个域中登录上花费的时间，也包括登录失败所浪费的时间。
l 通过让用户减少提交和记忆认证信息，来有效改善安全性。
l 在系统管理员添加和移除用户，以及修改用户操作权限上，大大提高效率。
l 通过采用统一用户账号配置，包括更加一致的控制和移除个别用户访问系统资源的权限，来增强系统的安全性。
3. SSO成熟产品及其应用
目前市场上，已经存在又一些成熟的单点登陆产品，或者规范。以下就列举两个具有代表性的产品，并且针对其特点进行简单的介绍。
l Microsoft .Net Passport
Microsoft的.Net Passport 是我们最为常见的SSO认证平台，MSN的用户登录以及管理就是在此平台上进行的。使用.Net Passport实施SSO的的最大缺点是，对原有的应用系统的集成存在较大难度，甚至需要对原有的应用系统的做较大的改动，来符合.Net Passport的认证接口。而且采用此体系的应用系统，同时也必须构筑在Windows平台服务器上。
l 安盟SecurID系统
这套系统是国内最为成熟的产品之一，此系统在认证时，安盟SecurID向授权的员工登记发放令牌, 生成令牌码，令牌码随时间变化。每60秒就会生成一个随机令牌码, 保护网络的安盟认证服务器能够验证这个变化的代码是否有效。每个认证令牌都是唯一的。别人不能通过记录以前的令牌码来预测将来的令牌码，结合令牌码用户必须提供其记忆的PIN,这样，如果某个用户提供了一个正确的PIN+令牌码,就可以高度确信该用户即是合法用户。这样的做法固然有很强的安全性，但是令牌的领取，以及每次都要使用不同的令牌码，就给用户造成使用上的不便。而系统在设计上，对令牌码生成、时间的漂移、同步有很高的要求，也就造成系统的在这方面的复杂程度。另外，它对旧系统的集成，也存在缺陷。
4. SSO安全性特征
l 次域在访问时，必须被强迫信任主域。
这就意味者，对主域的信任高于对次域的信任，凡经过主域认证的用户，都将有权访问次域。进一步的，主域必须确定用户在次域的活动权限。
l 终端用户的身份和认证证书的正确性和合法性的判断。
l 在未认证的使用者请求次域上的服务时，必须保护好认证证书的安全性。
l 当在主域和次域间传输认证标识时，认证标识必须受到保护，以防止中途拦截进行偷窃、以及篡改导致的伪装攻击。
第二章 Web SSO系统需求分析
福富Web单点登陆系统，简称FS-SSO，针对以上所说的特点，来提出需求的。
1. 浅层需求
u 名称：登陆平台
u 描述
v 用户访问AppServer（应用服务器），因为没有访问权限，而转向SSO Server进行登陆，登陆系统以后获得访问App Server的权限。
v 用户直接访问SSO Server，进行登陆，然后根据需要，转向需要的App Server。
v 每次登录都有一个登陆有效期，如果超时，此次登陆请求将不予以接受，必须重新申请登录。（这点需求是在设计过程中增补的，它可以有效的增加登录的安全性，后面的架构设计中，更可明显的反映出它的必要性）
u 名称：注册新用户
u 描述
v 注册的信息包括：用户名、密码以及邮箱、个人说明等个人信息
u 名称：修改用户信息
u 描述
v 注册过的用户可以修改自己的信息。
u 名称：激活用户
u 描述
v 管理员给新注册的用户，分配其所属的用户组，有权访问的应用，以及操作、访问的权限，并激活这个账号（可以允许自动激活）
u 名称：管理用户
u 描述
v 用户帐号的激活、停用，批量用户操作
u 名称：管理接入平台的应用
u 描述
v 管理接入平台的列表、平台的信息
v 管理与此应用有关联的用户
u 名称：管理角色
u 描述
v 管理角色层次、角色信息，配置角色所具有的权限
u 名称：管理用户权限
u 描述
v 管理用户权限层次、权限信息
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. Web SSO 认证机制架构设计
很显然，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协议具有以下的一些优势：
l 与授权机制相结合
l 实现了一次性签放的机制，并且签放的票据都有一个有效期；
l 支持双向的身份认证，既服务器可以通过身份认证确认客户方的身份，而客户如果需要也可以反向认证服务方的身份；
l 支持分布式网络环境下的认证机制，通过交换"跨域密钥"来实现。
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. Web SSO 权限控制架构设计
高级的权限模型是把权限与平台系统的功能资源相关联（而非物理资源），这种设计权限的分配通常被结合到各个模块，或者模块的积累中，所以对于接入平台的旧系统，平台不便也不必要对它的权限系统进行改造。但对于准备在平台上搭建的新系统，则必须提供一个便捷、统一的模型，使得新系统即能方便的建立起符合自己功能需要的权限体系，又能够在SSO平台中，对用户的权限进行统一分配。
2.1. 用户—角色－应用服务－权限模型
有别于一般的用户-角色-权限模型，用户-角色--应用服务权限模型中添加了应用服务对象。从逻辑上分析，每个应用所需要的权限是不同的，即每种角色在不同的应用上的权限是不同的。而SSO是用于统一管理的平台，对于复杂的权限和系统设计紧密结合，所以权限不适合集成到SSO中。同时应用服务要在SSO留有信息，就必须在SSO上加入应用服务对象（实际上应用服务在SSO上注册的信息中就包含所有权限的信息）。
管理员在分配权限的时候，将应用的权限分配给角色，角色分配给用户。在用户通过登陆认证以后，SSO根据用户的信息，分配给用户具备访问权限的应用服务，在每次用户进入这个服务时，SSO再把权限的列表提交给应用服务，这时用户才真正取得操作的权限。
为了能够更加细致、方便的管理权限和角色，角色和权限被设计为具有继承的特性。也就是说，角色和角色可以有树状层次关系，处于父结点的角色包含有子节点角色具有的权限。而权限的结构也和角色的结构类似。
SSO系统，相当于整个平台中的一个特殊的应用服务，所以对于这个应用服务也要有授权，它的授权有MT来控制。
2.2. 应用服务权限接口模型
当用户获得ST以后将ST交给Agent，并通过Agent的校验。ST中还包括了权限的标识的列表。这些标识交给应用服务后，应用服务就可以限制用户的操作。
通过上面描述的树状权限结构，可以把一类的权限归并于一个权限集下，这样可以大大的减少ST中的数据量。这样权限实际上又被分为，与操作直接关联的基本权限，和由多个权限组合而成的组合权限。
由于基本权权限与设计直接相关，所以基本权限权限的数量和代表的操作是不会变动的；组合权限虽然不会经常发生变动，但是还是会有变化。因此，SSO和应用服务之间的组合权限的结构需要同步。
对于权限的管理，必须先进入某个应用服务的域，即具有这个应用服务的域的权限管理。这时，MT可以发挥其对用户所在的应用服务的域的监控，用户未进入应用服务的域中（除SSO应用服务域外），即使具有管理权限的能力，也不能对这个域的权限进行管理。
第四章 Web SSO系统的设计与实现
1. Web SSO 认证概要设计
针对Agent的特点，使用服务器的过滤器（也叫筛选器，Filter），来实现其功能最为合适。目前主流的IIS服务器和基于Servlet容器的JAVA都有Filter的接口（Servlet2.3标准以后版本支持Filter接口类）。
筛选器的功能是在请求交给服务器处理之间，和服务器响应的消息发出给Client之前对消息进行处理。使用筛选器可以大大增强服务器的功能。使用 Internet服务器API 筛选器，用诸如增强的HTTP请求记录、自定义加密和压缩方案、新的身份验证方法等自定义功能来增强 Internet 服务器。筛选器应用程序处于客户端的网络连接与 HTTP 服务器之间。根据筛选器应用程序请求通知的选项，它可以作用于若干服务器操作。可对筛选器进行设置，使其在选定的事件发生时接收通知，这些事件包括读取客户端的原始数据、处理标头、使用个人通信技术 (PCT) 和安全套接字层 (SSL) 通过安全端口管理通信，或在处理 HTTP 请求时处理其他步骤。
Agent的设计要考虑的主要问题是，如何无缝的继承旧系统的登陆过程。首先，对目前Web登陆的过程做简单的分析，可以得出不论是什么系统、基于什么技术，登陆过程都将使用表单回传数据，数据由服务器交给CGI来进行处理。因此，只要从SSO库中保存原系统的用户名、密码，然后使用Agent修改Http请求，加入这些信息，然后再交给给服务器，就可以实现登陆。具体来说，对于
Servlet机制，页面用的都是普通HTML元素，回传的数据都由doPost和doGet进行处理。但是，如果使用的.Net机制，它在Web上实现了事件的驱动，由于其特殊的事件消息传递封装方式（具体传递方式此处不详细描述），使得在回传过程中某些用于触发事件的关键信息是必不可少的，如果缺少，事件将不会触发，事件中用于判断用户登录的流程也不会执行。Servlet上流行的Struts架构的下一代技术，也将采用事件机制，其概念也将与.Net类似。所以，就要更为彻底的利用原有的登陆页面，对发送的登陆页面进行修改，给表单填入必要信息，并使登陆页面自动提交表单，然后再将原系统的登陆信息给入HTTP请求。
针对IIS服务器的Filter设计如图所示。根据ISAPI Filter的接口为OnReadRawData和OnSendRawData，可以在HTTP消息接收和HTTP响应发送时进行截获。图中所示的流程的基本内容和前文架构设计的流程一致的。需要说明的是，在取得应用服务的授权过程中，对于接入平台的旧系统，就如上图描述的，将修改入口页面（一般是登陆页），加入客户端脚本，使其能够自动提交，然后再修改提交的HTTP请求，在消息体中（Message-Body）加入必要信息（一般是旧系统的登陆用户名和密码，以及其他一些信息），辅助旧应用服务系统完成认证和授权。对于新应用服务系统而言，在请求入口页面的时候，就直接可以修改HTTP的请求，把从SSO取得的权限标识列表数据加入HTTP请求的消息体中，提交给给用户授权的CGI进行处理。
对于Servlet的javax.servlet.Filter，其接口函数是doFilter，虽然doFilter同时处理发往应用服务的HTTP请求和应用服务响应的HTTP消息，但是本质上和ISAPI Filter没有太大差别，上面描述的设计基本使用。
2. Web SSO应用服务概要设计
由于在.Net平台上的开发，工具便捷，Frameworks强大，开发周期短，适合中小型项目和部分大型项目。而SSO应用服务的规模十分的小，实际上只有普通系统的认证授权模块，所以，目前SSO应用服务将针对.Net平台进行设计。
2.1. 表现层
由于在Asp.Net中，Frameworks封装了许多的服务器控件，以及采用事件驱动的模式框架，使得表现层的开发和单纯的HTML开发，基本无异。主要的页面有：
1. 登陆页面：用户登录SSO，生成MT，接收TGT,生成ST。
2. 应用维护页面：增删改查在SSO注册的应用。
3. 应用注册/编辑页面：注册新的应用，或者编辑已注册的应用的信息。
4. 角色维护页面：增删改查在SSO注册的角色，增删角色具有的权限，以及管理角色的树状层次。
5. 角色注册/编辑页面：添加新的权限或者编辑权限信息。
6. 权限维护页面：增删改查在SSO注册的权限，以及管理权限的树状层次。
7. 权限注册/编辑页面：添加新的权限，或者编辑已注册的权限信息。
8. 用户组、用户维护页面：增删改查在SSO注册的用户组、用户，以及管理用户组的树状层次。
9. 用户组注册/编辑页面：添加新的用户组，或者已编辑注册的用户组信息。
10.用户注册/编辑页面：添加新的用户组，或者已编辑注册的用户组信息。
2.2. 业务层
使用Asp.Net的Code Behind方式，业务层的模块和表现层的模块是一一对应的，表现层的触发的事件也将由服务器控件在业务层模块注册的事件进行来处理。
以下列部分举了业务层数据对象的结构（按照ASN.1编码规范）：
用户::= SET
{
ID INTEGER,
用户名 OCTET STRING,
密码 OCTET STRING，
应用列表 SEQUENCE OF 应用
角色列表 SEQUENCE OF 角色,
权限列表 SEQUENCE OF 权限,
用户组列表 SEQUENCE OF 用户组,
}
角色::= SET
{
ID INTEGER,
名称 OCTET STRING,
说明 OCTET STRING，
权限列表 SEQUENCE OF 权限，
父角色ID INTEGER
}
权限::= SET
{
ID INTEGER,
名称 OCTET STRING,
说明 OCTET STRING,
父权限ID INTEGER
}
用户组::= SET
{
ID INTEGER,
名称 OCTET STRING,
说明 OCTET STRING,
父组ID INTEGER，
用户列表 SEQUENCE OF 用户
}
应用::=SET
{
ID INTEGER,
名称 OCTET STRING,
说明 OCTET STRING,
密钥 OCTET STRING,
权限列表 SEQUENCE OF 权限
}
SSO收到的TGT::=SET
{
应用服务会话ID OCTET STRING,
会话密钥 OCTET STRING,
请求的服务标识 OCTET STRING,
上次请求地址 OCTET STRING,
发出请求的客户端IP OCTET STRING,
发出票据事件 UTCTIME,
票据失效时间 UTCTIME
}
MT::=SET
{
已授权的应用服务ID列表 SEQUENCE OF OCTET STRING,
子会话密钥 OCTET STRING,
用户ID OCTET STRING,
发出请求的客户端IP OCTET STRING,
发出票据事件 UTCTIME,
票据失效时间 UTCTIME
}
ST::=SET
{
应用服务会话ID OCTET STRING,
已授权的权限ID列表 SEQUENCE OF OCTET STRING,
用户ID OCTET STRING,
发出请求的客户端IP OCTET STRING,
发出票据事件 UTCTIME,
票据失效时间 UTCTIME
}
2.3. 数据层
在数据层上，可以先利用.Net的反射机制搭建数据行基类，它可以自动根据类属性的类型、数量，将数据库中的数据行实例化为类，也能把新的类数据或修改的类数据保存入数据库。这样只需要，建立与数据库中的数据行具有映射关系的类，并继承数据行基类便可以方便进行数据项存取操作了。
2.4. 票据加密
系统目前采用DES对票据加密，严格意义上，DES加密时不安全的，容易破解的。按照Kerberos5标准中描述的，其提供了多种可选择的加密方案，以加大攻击的难度。所以SSO将逐步改进其加密机制，使其完善。
结束语
最然，FS-SSO平台属于小规模的项目，但是由于其独特的需求，使其在开发上有一定的难度。目前，已经基本解决设计上的问题，对于系统依赖的加密机制，尚未有一个壮硕的设计，还需要不断改进。另外，由于水平有限，对于Kerberos5标准仍未有深入的理解，对于票据的设计乃至整个系统的设计，都还有许多的细节需要斟酌，需要改进。
致谢
感谢福富软件技术股份有限公司政企部提供的FS-SSO项目开发平台和资源。特别感谢，公司的指导老师赖金辉和学校指导老师黄志华，在项目设计和毕业设计上给于的指导和帮助。也感谢在这两年的软件学院学习中，给予我指导的老师。感谢你们给予我的关心和帮助才使得我的在软件技术的学习上不断进步。
参考文献
1. 《Introduction to Single Sign-On》: Opengroup,
http://www.opengroup.org/security/sso_intro.htm
2. 《用 Kerberos 为 J2ME 应用程序上锁》：Faheem Khan，http://www-900.ibm.com/developerWorks/cn/java/wi-kerberos/#
3. 《SSL简介及其安全性》，Charl Van Der Walt，http://www.nsfocus.net/index.php?act=magazine&do=view&mid=804
4. 《The Kerberos Network Authentication Service (V5)》（RFC1510）：J. Kohl、C. Neuman， Page 5-9、Page 67-77
5. 《Simplify enterprise Java authentication with single sign-on》：Faheem Khan，
http://www-106.ibm.com/developerworks/java/library/j-gss-sso/
6. 《Hypertext Transfer Protocol -- HTTP/1.1》（RFC2616）：R. Fielding、J. Gettys、H. Frystyk、L. Masinter、P. Leach、T. Berners-Lee、June 1999，Paga 31-43、Page 51-71、118
7. 《ISAPI 筛选器》，MSDN 2003：Microsoft Corporation，
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.2052/vccore/html/_core_isapi_extensions.3a_.filters.htm
8. 《Server Variables》，MSDN 2003：Microsoft Corporation，
ms-help://MS.MSDNQTR.2003FEB.2052/iisref/htm/ServerVariables.htm
