于基net的单点登录sso解决方案设计--毕业设计.doc

基于.Net的单点登录(SSO)解决方案毕业设计论文 前些天一位朋友要我帮忙做一单点登录，其实这个概念早已耳熟能详，但实际应用很少，难得最近轻闲，于是决定通过本文来详细描述一个SSO解决方案，希望对大家有所帮助。SSO的解决方案很多，但搜索结果令人大失所望，大部分是相互转载，并且描述的也是走马观花。 闲话少叙，进入正题，我的想法是使用集中验证方式，多个站点集中Passport验证。如下图所示： 为方便清晰描述，先定义几个名词，本文中出现之处均为如下含义。主站：Passport集中验证服务器。分站：凭证：用户登录后产生的数据标识，用于识别授权用户，可为多种方式，DEMO中主站我使用的是Cache，分站使用Session。令牌：由Passport颁发可在各分站中流通的唯一标识。 OK，现在描述一下单点登录的过程： 情形一、匿名用户：匿名用户访问分站a上的一个授权页面，首先跳转到主站让用户输入帐号、密码进行登录，验证通过后产生主站凭证，同时产生令牌，跳转回分站a，此时分站a检测到用户已持有令牌，于是用令牌再次去主站获取用户凭证，获取成功后允许用户访问该授权页面。同时产生分站a的本地凭证，当该用户需要再次验证时将先检查本地凭证，以减少网络交互。 情形二、在分站a登录的用户访问分站b：因为用户在分站a登录过，已持有令牌，所以分站b会用令牌去主站获取用户凭证，获取成功后允许用户访问授权页面。同时产生分站b的本地凭证。 设计完成后，接下来是方案实现的一些关键点： 令牌：令牌由主站颁发，主站颁发令牌同时生成用户凭证，并记录令牌与用户凭证之间的对应关系，以根据用户提供的令牌响应对应的凭证；令牌要在各跨域分站中进行流通，所以DEMO中令牌我使用主站的Cookie，并指定Cookie.Domain=。各分站如何共享主站的Cookie？从分站Redirect到主站页面，然后该页面读取Cookie并以URL参数方式回传即可，可在DEMO代码中查看详细实现，当然如果哪位有更好的令牌实现方式也拿出来分享。/产生令牌stringtokenValue=Guid.NewGuid().ToString().ToUpper();HttpCookietokenCookie=newHttpCookie(Token);tokenCookie.Values.Add(Value,tokenValue);tokenCookie.Domain=;Response.AppendCookie(tokenCookie); 主站凭证：主站凭证是一个关系表，包含了三个字段：令牌、凭证数据、过期时间。有多种实现方式可供选择，要求可靠的话用数据库，要求性能的话用Cache，DEMO中我使用的是Cache中的DataTable。如下代码所示：/初始化数据结构/-/|token(令牌)|info(用户凭证)|timeout(过期时间)|/|-|/privatestaticvoidcacheInit()if(HttpContext.Current.CacheCERT=null)DataTabledt=newDataTable();dt.Columns.Add(token,Type.GetType(System.String);dt.Columnstoken.Unique=true;dt.Columns.Add(info,Type.GetType(System.Object);dt.Columnsinfo.DefaultValue=null;dt.Columns.Add(timeout,Type.GetType(System.DateTime);dt.Columnstimeout.DefaultValue=DateTime.Now.AddMinutes(double.Parse(System.Configuration.ConfigurationManager.AppSettingstimeout);DataColumnkeys=newDataColumn1;keys0=dt.Columnstoken;dt.PrimaryKey=keys;/Cache的过期时间为令牌过期时间*2HttpContext.Current.Cache.Insert(CERT,dt,null,DateTime.MaxValue,TimeSpan.FromMinutes(double.Parse(System.Configuration.ConfigurationManager.AppSettingstimeout)*2); 分站凭证：分站凭证主要用于减少重复验证时网络的交互，比如用户已在分站a上登录过，当他再次访问分站a时，就不必使用令牌去主站验证了，因为分站a已有该用户的凭证。分站凭证相对比较简单，使用Session、Cookie均可。 分站SSO页面基类：分站使用SSO的页面会做一系列的逻辑判断处理，如文章开头的流程图。如果有多个页面的话不可能为每个页写一个这样的逻辑，OK，那么把这套逻辑封装成一个基类，凡是要使用SSO的页面继承该基类即可。如下代码所示：usingSystem;usingSystem.Data;usingSystem.Configuration;usingSystem.Web;usingSystem.Web.Security;usingSystem.Web.UI;usingSystem.Web.UI.WebControls;usingSystem.Web.UI.WebControls.WebParts;usingSystem.Web.UI.HtmlControls;usingSystem.Text.RegularExpressions;namespaceSSO.SiteA.Class/授权页面基类/publicclassAuthBase:System.Web.UI.PageprotectedoverridevoidOnLoad(EventArgse)if(SessionToken!=null)/分站凭证存在Response.Write(恭喜，分站凭证存在，您被授权访问该页面！);else/令牌验证结果if(Request.QueryStringToken!=null)if(Request.QueryStringToken!=$Token$)/持有令牌stringtokenValue=Request.QueryStringToken;/调用WebService获取主站凭证SSO.SiteA.RefPassport.TokenServicetokenService=newSSO.SiteA.RefPassport.TokenService();objecto=tokenService.TokenGetCredence(tokenValue);if(o!=null)/令牌正确SessionToken=o;Response.Write(恭喜，令牌存在，您被授权访问该页面！);else/令牌错误Response.Redirect(this.replaceToken();else/未持有令牌Response.Redirect(this.replaceToken();/未进行令牌验证，去主站验证elseResponse.Redirect(this.getTokenURL();base.OnLoad(e);/获取带令牌请求的URL/在当前URL中附加上令牌请求参数/privatestringgetTokenURL()stringurl=Request.Url.AbsoluteUri;Regexreg=newRegex(.*?.+=.+$);if(reg.IsMatch(url)url+=&Token=$Token$;elseurl+=?Token=$Token$;return+Server.UrlEncode(url);/去掉URL中的令牌/在当前URL中去掉令牌参数/privatestringreplaceToken()stringurl=Request.Url.AbsoluteUri;url=Regex.Replace(url,(?|&)Token=.*,RegexOptions.IgnoreCase);return+Server.UrlEncode(url);/endclass 用户退出：用户退出时分别清空主站凭证与当前分站凭证。如果要求A站点退出，B、C站点也退出，可自行扩展接口清空每个分站凭证。 主站过期凭证/令牌清除：定时清除(DataTable)Cache“CERT”中timeout字段超过当前时间的记录。单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。通常情况下运维内控审计系统、4A系统或者都包含此项功能，目的是简化账号登陆过程并保护账号和密码安全，对账号进行统一管理。企业应用集成（EAI, Enterprise Application Integration）。企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。事实上，还有一个层面上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。在信息安全管理中，访问控制(Access Controls)环绕四个过程：Identification；Authentication；Authorization；Accountability。单点登录（Single Sign On）属于Authorization授权系统，除单点登录外还包括：Lightweight Directory Access Protocol 和 Authorization ticket。（Michael E. Whitman (2011)Management Of Information SecurityKennesaw University)编辑本段技术实现机制当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。编辑本段技术实现及应用优势技术实现以金万维单点登录为例：如图所示：统一的身份认证系统主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。整个系统可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。应用优势单点登录：用户只需登录一次，即可通过单点登录系统（eTrueSSO）访问后台的多个 应用系统，二次登陆时无需重新输入用户名和密码C/S单点登录解决方案：无需修改任何现有的应用系统服务端和客户端即可实现C/S单点登录系统即装即用：通过简单的配置，无须用户修改任何现有B/S、C/S应用系统即可使用应用灵活性：内嵌金万维动态域名解析系统（gnHost），可独立实施，也可结合金万维异速联/天联产品使用基于角色访问控制：根据用户的角色和URL实现访问控制功能全面的日志审计：精确地记录用户的日志，可按日期、地址、用户、资源等信息对日志进行查询、统计和分析集群：通过集群功能，实现多台服务器之间的动态负载均衡传输加密：支持多种对称和非对称加密算法，保证用户信息在传输过程中不被窃取和篡改可扩展性：对后续的业务系统扩充和扩展有良好的兼容性存在的问题与需求奇正藏药集团公司坐落于兰州，在西藏、北京、上海等地拥有多个分子公司，并在全国各大城市设有办事处，随着业务的快速发展与壮大，集团公司已经意识到信息化是实现企业终极目标的重要手段，自2000年开始，公司先后实施了ERP、BPM、HR、EIP、企业邮局、腾讯通平台、OA、财务等多套管理系统，实现公司各项业务流程及管理流程的信息化、自动化。然而，随着业务数量的不断增加，各系统之间互不兼容造成的信息共享性差、需要记忆多套密码、客户端维护成本高等问题日益凸显，一些花巨资购买并实施数月的系统运用效果远不如预期理想。为了确保业务的高效运行与管理的高效执行，企业急需优化信息化方案：第一， 如何实现公司各种业务流程及信息资源的全面整合？第二， 如何简化各种信息系统的使用方式，降低使用成本？第三， 如何降低信息系统维护与管理成本？解决方案实现资源整合：为了解决第一个问题，即实现各信息系统之间的全面整合，集团公司引进了企业信息门户(EIP)，即将各种应用系统(诸如ERP、BPM、HR、OA、企业邮局等)、数据资源和互联网资源统一集到企业信息门户之下,根据每个用户使用特点和角色的不同,形成个性化的应用界面，并通过对事件和消息的处理、传输把用户有机地联系在一起。简化系统应用：在实施EIP的过程中，集团公司使用金万维单点登录eTureSSO解决用户需要记录多个系统账号的问题，用户只需要在第一次访问信息系统时，输入用户名与密码，以后再访问同一个系统资源时，无需再次输入，由单点登录系统自动登录。降低信息维护成本：金万维异速联(E-SoonLink)实现C/S分布式软件的集中式部署，将管理系统服务器端与客户端统一部署在客户服务器中心，任何授权客户机都能够以WEB形式访问，并更新数据，轻松实现了系统在广域网中的局域网应用。奇正藏药集团在实施异速联系统之后，无需在每个用户客户机安装每套信息系统的客户端软件，因此对客户机硬件配置要求降低，另外，无需对每个客户机进行安装配置和维护，大大减少了安装维护的工作量，降低了用户数量日益增长所产生的信息化成本。浅析用户权限管理系统中的单点登录概述：用户权限管理系统中的单点登录是一种常用于企业内部网络的访问网络技术，可以将企业中所有域的用户登录和用户账号管理进行集中。用户权限管理系统中的单点登录是一种常用于企业内部网络的访问网络技术，可以将企业中所有域的用户登录和用户账号管理进行集中。 如果在权限管理系统中不引入单点登录，在企业中承担审批权限的人员对于企业中的各种应用系统如CRM、OA、HR等，将需要记住多个系统的用户登录信息，此外还需要多次的进行登录操作，极大的影响了信息化管理的快捷性和高效性。 另一方面多个应用系统需要多个用户管理，在一方面也为系统管理员维护系统增加了工作量。如果在一个企业中有6个应用系统，一次若是变更10个人员，系统管理员也需要维护60个人的信息，然而想这样的企业调整的人员信息肯定不止10人，这中原始的信息管理方法极大的阻碍的信息管理的高效性。 通过单点登录功能，每个用户只需要记录一个用户名和密码，登录一个系统之后，即可实现多个系统的透明跳转。还可进行实行统一的用户管理系统，系统管理员也值需要维护一套人员信息，改变信息时通过平台接口同步更新至各个应用系统，实现人员系统单次维护全公司同步变更，大大提高了工作效率。慧都UPMS通用用户权限系统现全面升级，针对不同应用系统提供了用户权限模块的基础框架和通用模型，还计入了包括单点登录在内的一些新功能，帮助开发者快速实施和开发出符合不同需求的用户权限管理模块。 通过慧都的UPMS通用用户权限系统，用户只需要对接入的应用系统设置勾选开启单点登录，便可只输入一次用户名密码，即可访问权限允许的所有接入系统，如下图： 在这次的UPMS通用用户权限系统升级中加入了单点登录功能，用户可在UPMS中，可对接入系统进行进行勾选设置，来确认是否开启单点登录功能，如下图：通过UPMS通用用户权限系统中的单点登录可实现多种价值： 节省用户在不同系统中登录所用时 减少用户登录出错的几率 强化了安全性 减少系统管理员增、删、改用户权限时间 不用处理或是保存多个系统用户的认证信息 简单操作实现用户登录和账号的集中管理采用CAS原理构建单点登录单 点登录（SingleSignOn,简称SSO）是目前比较流行的服务于企业业务整合的解决方案之一，SSO使得在多个应用系统中，用户 只需要登录一次就可以访问所有相互信任的应用系统。IBM对SSO有一个形象的解释“单点登录、全网漫游”。1.CAS介绍CAS是Yale大学发起的一个开源项目，旨在为Web应用系统提供一种可靠的单点登录方法，CAS在2004年12月正式成为JA-SIG的一个项目。CAS具有以下特点： 开源的企业级单点登录解决方案。 CASServer为需要独立部署的Web应用。 CASClient支持非常多的客户端(这里指单点登录系统中的各个Web应用)，包括Java,.Net,PHP,Perl,Apache,uPortal,Ruby等。2.CAS原理和协议从 结构上看，CAS包含两个部分：CASServer和CASClient。CASServer需要独立部署，主要负责对用户的认证工 作；CASClient负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CASServer。图1是CAS最基本的协议过程：图1.CAS基础协议CASClient与 受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。（1）对于访问受保护资源的每个Web请求，CASClient会分析该请求 的Http请求中是否包含ServiceTicket，如果没有，则说明当前用户尚未登录。（2）于是将请求重定向到指定好 的CASServer登录地址，并传递Service（也就是要访问的目的资源地址），以便登录成功过后转回该地址。（3）用户输入认 证信息，如果登录成功，CASServer随机产生一个相当长度、唯一、不可伪造的ServiceTicket，并缓存以待将来验证。（4）系统自 动重定向到Service（也就是要访问的目的资源地址）地址，并为客户端浏览器设置一个TicketGrantedCookie（TGC）。（5,6）CASClient在拿 到Service和新产生的Ticket过后，与 CASServer进行身份核实，以确 保ServiceTicket的合法性。在该协议中，所有与CAS的交互均采用SSL协议，确保，ST和TGC的安全性。协议工作过程中会有2次重定向的过程，但是CASClient与CASServer之间进行Ticket验证的过程对于用户是透明的。另外，CAS协议中还提供了Proxy（代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考CAS官方网站上的相关文档。 用户在单点登录服务器的登录页面中，输入用户名和密码。 然后单点登录服务器会对用户名和密码进行认证。 认证本身并不是单点登录服务器的功能，因此，通常会引入某种认证机制。认证机制可以有很多种，例如自己写一个认证程序，或者使用一些标准的认证方法，例如 LDAP或者数据库等等。在大多数情况下，会使用LDAP进行认证。这是因为LDAP在处理用户登录方面，有很多独特的优势，这在本文的后面还会比较详细 地进行介绍。 认证通过之后，单点登录服务器会和应用程序进行一个比较复杂的交互，这通常是某种授权机制。CAS使用的是所谓的Ticket。具体这点后面还会介绍。 授权完成后，CAS把页面重定向，回到Web应用。Web应用此时就完成了成功的登录（当然这也是单点登录的客户端，根据返回的Ticket信息进行判断成功的）。 然后单点登录服务器会在客户端创建一个Cookie。注意，是在用户的客户端，而不是服务端创建一个Cookie。这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。 如 果用户此时希望进入其他Web应用程序，则安装在这些应用程序中的单点登录客户端，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输 入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。登录之后，CAS重定向回到用户的应用程序。这样，就不再需要用户继续输入用户名和密码，从而实现了单点登录。注意，这种单点登录体系中，并没有通过http进行密码的传递（但是有用户名的传递），因此是十分安全的。CAS 被设计为一个独立的Web应用，目前是通过若干个Java servlets来实现的。CAS必须运行在支持SSL的web服务器至上。应用程序可以通过三个URL路径来使用CAS，分别是登录URL（login URL），校验URL（validation URL）和登出URL（logout URL）。 应用程序一开始，通常跳过原来的登陆界面，而直接转向CAS自带的登录界面。当然也可以在应用程序的主界面上增加一个登录之类的按钮，来完成跳转工作。 如果用户喜欢的话，也可以手工直接进入CAS的登录界面，先进行登录，在启动其他的应用程序。不过这种模式主要用于测试环境。 CAS的登录界面处理所谓的“主体认证”。它要求用户输入用户名和密码，就像普通的登录界面一样。 主体认证时，CAS获取用户名和密码，然后通过某种认证机制进行认证。通常认证机制是LDAP。 为了进行以后的单点登录，CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。这个cookie称为“ticket-granting cookie”，用来表明用户已经成功地登录。 认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。 主体认证完成后，CAS将用户的浏览器重定向，回到原来的应用。CAS客户端，在从应用转向CAS的时候，同时也会记录原始的URL，因此CAS知道谁在调用自己。CAS重定向的时候，将ticket作为一个参数传递回去。 例 如原始应用的网址是 / CAS完成主体认证后，会使用下面URL进行重定向 ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。 收到ticket之后，应用程序需要验证ticket。这是通过将ticket 传递给一个校验URL来实现的。校验URL也是CAS服务器提供的。 CAS通过校验路径获得了ticket之后，通过内部的数据库对其进行判断。如果判断是有效性，则返回一个NetID给应用程序。 随后CAS将ticket作废，并且在客户端留下一个cookie。 以后其他应用程序就使用这个cookie进行认证（当然通过CAS的客户端），而不再需要输入用户名和密码。单点登录（SSO）的技术被越来越广泛地运用到各个领域的软件系统当中。本文从业务的角度分析了单点登录的需求和应用领域；从技术本身的角度分析了单点登录技术的内部机制和实现手段，并且给出Web-SSO和桌面SSO的实现、源代码和详细讲解；还从安全和性能的角度对现有的实现技术进行进一步分析，指出相应的风险和需要改进的方面。本文除了从多个方面和角度给出了对单点登录（SSO）的全面分析，还并且讨论了如何将现有的应用和SSO服务结合起来，能够帮助应用架构师和系统分析人员从本质上认识单点登录，从而更好地设计出符合需要的安全架构。关键字：SSO, Java, J2EE, JAAS1 什么是单点登陆单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。较大的企业内部，一般都有很多的业务支持系统为其提供相应的管理和IT服 务。例如财务系统为财务人员提供财务的管理、计算和报表服务；人事系统为人事部门提供全公司人员的维护服务；各种业务系统为公司内部不同的业务提供不同的 服务等等。这些系统的目的都是让计算机来进行复杂繁琐的计算工作，来替代人力的手工劳动，提高工作效率和质量。这些不同的系统往往是在不同的时期建设起来 的，运行在不同的平台上；也许是由不同厂商开发，使用了各种不同的技术和标准。如果举例说国内一著名的IT公司（名字隐去），内部共有60多个业务系统，这些系统包括两个不同版本的SAP的ERP系统，12个不同类型和版本的数据库系统，8个不同类型和版本的操作系统，以及使用了3种不同的防火墙技术，还有数十种互相不能兼容的协议和标准，你相信吗？不要怀疑，这种情况其实非常普遍。每一个应用系统在运行了数年以后，都会成为不可替换的企业IT架构的一部分，如下图所示。随 着企业的发展，业务系统的数量在不断的增加，老的系统却不能轻易的替换，这会带来很多的开销。其一是管理上的开销，需要维护的系统越来越多。很多系统的数 据是相互冗余和重复的，数据的不一致性会给管理工作带来很大的压力。业务和业务之间的相关性也越来越大，例如公司的计费系统和财务系统，财务系统和人事系 统之间都不可避免的有着密切的关系。为了降低管理的消耗，最大限度的重用已有投资的系统，很多企业都在进行着企业应用集成（EAI）。 企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用 户界面上的“通用企业门户”等等。事实上，还用一个层面上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。通常来说，每个单独的系统都会有自己的安全体系和身份认证系统。整合以前，进入每个系统都需要进行登录，这样的局面不仅给管理上带来了很大的困难，在安全方面也埋下了重大的隐患。下面是一些著名的调查公司显示的统计数据：用户每天平均 16 分钟花在身份验证任务上 - 资料来源： IDS频繁的 IT 用户平均有 21 个密码 - 资料来源： NTA Monitor Password Survey49% 的人写下了其密码，而 67% 的人很少改变它们每 79 秒出现一起身份被窃事件 - 资料来源：National Small Business Travel Assoc全球欺骗损失每年约 12B - 资料来源：Comm Fraud Control Assoc到 2007 年，身份管理市场将成倍增长至 $4.5B - 资料来源：IDS使用“单点登录”整合后，只需要登录一次就可以进入多个系统，而不需要重新登录，这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。请看下面的统计数据：提高 IT 效率：对于每 1000 个受管用户，每用户可节省$70K帮助台呼叫减少至少1/3，对于 10K 员工的公司，每年可以节省每用户 $75，或者合计 $648K生产力提高：每个新员工可节省 $1K，每个老员工可节省 $350 资料来源：GigaROI 回报：7.5 到 13 个月 资料来源：Gartner另外，使用“单点登录”还是SOA时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应用的难点之一，应此建立“单点登录”的系统体系能够大大简化SOA的安全问题，提高服务之间的合作效率。2 单点登陆的技术实现机制随着SSO技术的流行，SSO的产品也是满天飞扬。所有著名的软件厂商都提供了相应的解决方案。在这里我并不想介绍自己公司（Sun Microsystems）的产品，而是对SSO技术本身进行解析，并且提供自己开发这一类产品的方法和简单演示。有关我写这篇文章的目的，请参考我的博客（单 点登录的机制其实是比较简单的，用一个现实中的例子做比较。颐和园是北京著名的旅游景点，也是我常去的地方。在颐和园内部有许多独立的景点，例如“苏州 街”、“佛香阁”和“德和园”，都可以在各个景点门口单独买票。很多游客需要游玩所有德景点，这种买票方式很不方便，需要在每个景点门口排队买票，钱包拿 进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要在每个景点门 口出示一下刚才买的套票就能够被允许进入每个独立的景点。单点登录的机制也一样，如下图所示，当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录（1）；根据用户提供的登录