单点登录系统方案 篇1
1 企业信息门户系统总体架构设计
系统的总体功能概括为: (1) 框架功能:建立信息统一访问入口, 建立用户目录认证系统, 进行个性化配置、日常管理配置、管理报表配置、安装管理等。 (2) 协作功能:建立统一协作工作平台、建立统一搜索引擎、文档管理引擎、日程表/ 工作列表、讨论论坛等。 (3) 发布功能:内容架构定义、配置内容管理系统。 (4) 整合功能:连接ERP系统、资金结算系统, 进行数据整合、集中展现。 (5) 公文流转:实现灵活的办公、办文、办会的事务管理。
根据业务需求, 将项目任务分成四个子系统进行建设, 各子系统及其建设任务如下。 (1) 信息门户子系统, 实现各信息系统之间的统一用户认证, 建立起统一访问入口。能让用户根据自己的需求创建各自的 “企业信息门户”群。 (2) 协同办公子系统:在“企业信息门户”群中, 建立多级办公体系、搭建项目团队工作空间、丰富各种办公协作类应用, 形成集团统一的办公协作及知识资源管理平台。 (3) 知识管理与培训子系统:构建企业知识文档中心和企业学习中心, 对分散于企业每个员工的知识资料进行有效管理。 (4) 数据整合子系统:采用各种整合手段, 对ERP系统、资金结算系统、、MES系统等系统的数据进行集成, 使“企业信息门户”真正成为集办公信息、协作信息、业务信息、项目信息于一体的“统一信息门户”平台。
为了确保统一的入口和对用户登录及使用的透明, 集团总部的门户 (portal) 系统和下属企业的portal系统都将使用同样的域名, 通过下属企业用户和集团用户设置不同的DNS服务器, 解析成不同的IP地址来实现不同地区用户访问不同的服务器。对于OA、IDS和邮件系统由于是通过portal门户的单点登录进行访问的, 所以只需一次验证即可跨不同业务系统协同完成一次任务。
2. 单点登录系统总体设计
针对当前EIP系统发展的需要, 在企业内部存在大量B/S、C/S的应用系统, 比如资金结算系统、ERP系统、MES系统, 以及各种各样对内对外业务系统, 每个应用系统都有自己的认证模块与权限控制模块, 为了实现对这些系统所管理资源的访问控制, 真正做到“单点登录, 全网通行”的功能。提出一种新型单点登录, 使之更为实用、可靠地应用于EIP系统中。单点登录系统总体设计方案划分为“访问接口层”、“目录服务层”以及“目录接口层”三个层次, 如图1 所示。
接口层的访问:为应用程序提供集中认证服务的验证接口模块。针对不同模式的应用系统, 分为3 个功能模块:Share Point Server SSO、基于SSL CA安全的SSO认证中心和ADSI/LDAP Interface。
目录服务层:目录服务层是基于微软活动目录服务技术实现的。目录服务层为企业统一验证和资源管理提供一个基准记录, 在目录服务器内包含了企业内用户和各种资源信息以及访问权限信息, 为各种应用系统的验证过程提供一个参考标准, 使企业内部有统一权限的管理基础, 是实现SSO功能必不可少的部分之一。
轻量级目录访问协议的访问:轻量级目录访问协议 (LDAP) 访问接口是为了和其他支持LDAP的目录服务器以及用户管理系统进行交换的接口。这是因为企业在电子商务全面开展的过程中, 和其他职能部门、企业和同级企业门户网站之间往往有相互访问的需要。通过标准的LDAP协议, 使SSO系统能够和其他职能部门的目录服务系统和人力资源系统等可以管理用户验证信息的系统进行交互, 使他们之间相互验证成为可能。
3 Share Point Server SSO设计
基本思想是建立一个加密的数据库, 把用户的认证信息, 存到这个数据库中。当成功地验证了登录Share Point Server (SPS) 网站的用户身份以后, 就可以从加密的数据库中, 获得用户的信息, 从而用来访问其他的服务器或者一些第三方的服务器[2]。
在第一次访问与企业应用程序集成的Web Part时, 如果用户的凭据还没有存储在单点登录数据库中, 那么该用户将被重定向到一个登录表单, 这个表单提示用户输入访问企业应用程序所需要的适当凭据。登录表单中的字段编号、顺序和名称由管理员在应用程序定义中配置;登录表单就是基于这些配置设置自动生成的。
还需要在Web Part中编写代码来检查数据库中是否存在凭据, 并在必要时将用户重定向到登录表单。用户提供的凭据然后被存储在凭据存储区中, 并被映射到与该用户的SPS帐户相对应的Windows帐户。之后该用户将被重定向回原先的Web Part。Web Part中的代码然后以适合应用程序的方式从凭据存储区向应用程序提交凭据, 同时检索必要的信息, 随后在Web Part中向用户显示这些信息。
4 基于CA的SSO设计
该设计是为解决企业内部或外部B/S架构的网络应用系统中身份认证和安全传输问题[3]。使基于Web的应用程序能够通过一个通用的接口, 实现“单点登录、即可运行”的功能。
采用SSL客户端代理和SSL服务器代理机制, 使用证书机制认证用户身份, 将验证后的用户身份信息传递给应用系统, 同时在原有的B/S客户端与服务端之间建立一条高强度的加密通道, 实现数据的保密性和完整性, 保证数据的安全传输[4]。
该子系统主要包括客户端用户操作界面, 客户端登录代理, CA认证服务器, 登录凭证信息库, LDAP目录服务器, SSL通信, CA认证机构几个部分。LDAP目录服务器用来保存用户的数字证书、证书注销列表以及用户的基本信息等。
5 ADSI/LDAP Interface设计
ADSI/LDAP Interface (Active Directory Service Interfaces/Lightweight Directory Access Protocol ADSI/LDAP接口) 是基于业界标准目录访问协议的接口, 也是微软活动目录技术提供的, 让应用程序实现SSO功能的标准接口[5]。在将来开发的应用系统中, 只要利用ADSI/LDAP接口访问的SSO系统目录信息, 同步其验证信息, 就可以实现SSO的统一登录。
ADSI/LDAP接口意义在于为将来的应用开发提供了符合业界标准的标准接口, 是将来新应用程序应当遵循的验证接口, 应用系统不仅仅让用户拥有单点登录功能, 还使应用系统之间的信息和功能交换可以较容易地实现。
LADP SERVER用来保存和管理用户凭证, LADP DIR BASE是设计的重要部件。LADP DIR BASE的核心部件是目录信息树。目录中用来存储用户基本信息、部门信息及用户权限角色。当用户第一次登录完成后, LDAP SERVER就获取了用户的UID和在部门的角色信息, 并将其保存在凭证信息数据库DB中, 以后此用户就可以在规定的角色范围内免登录相应的应用系统。
6 结束语
本文通过以某企业信息门户需求为例, 指出了当前企业单点登录的不足之处, 提出了一种新型单点登录方案, 该方案使用了SPS SSO 、基于CA的SSO和ADSI/LDAP Interface等技术协调完成用户登录认证。该设计方案已经成功运行在某企业的门户平台中, 实践证明该方案不仅对现有的B/S架构、C/S架构业务系统可以全方位认证, 还可以为以后的系统扩展提供预留接口。但是该设计方案在用户并发数量较大时, 有较长的时间滞后性。此外单点登录技术还在不断完善, 网络攻击手段还在不断发展变化, 怎样才能更有效地克服用户数量瓶颈, 克服网络攻击, 是我们今后急需解决的问题。
参考文献
[1]邓绪水, 宋庭新, 黄必清.单点登录技术在企业资源集成中的应用[J].湖北工业大学学报, 2010 (02) .
[2]薛辉, 邓军.一个基于Share Point Portal Server2003的单点登录模型设计与实现[J].网络安全技术与应用, 2006 (05) .
[3]邓军, 叶柏龙, 薛辉.基于Web Access CA的单点登录技术解决方案[J].网络安全技术与应用, 2006 (09) .
[4]邓军, 叶柏龙.身份认证和安全传输方案的分析与设计[J].科学技术与工程, 2007 (02) .
单点登录系统方案 篇2
关键词：云环境,单点登录,用户认证,跨域,云服务
0 引言
云计算环境具有资源集中、用户海量、有偿按需服务等特点，云端存储了大量的用户敏感数据，一旦用户身份被仿冒，就很容易造成隐私和敏感数据的泄露，而70%的数据泄漏是通过外部的输入源带进系统的，所以为了保证云服务的安全，必须对进入系统的用户身份和其他输入源的身份有较强的认证[1,2]。身份认证是其他安全策略的基础，也是其他安全策略实现其安全功能的前提条件。随着云计算的不断成熟，提供的服务也越来越多，这些服务分布在不同的服务器，分布在不同机构的域中，每个服务都有属于自己的数据库，用户通过云终端登录虚拟桌面访问每一个服务时需要提供用户名密码或其他认证方式，在切换服务时进行越来越多的登录。这种相对分散繁琐的身份认证机制对用户造成极大的精神负担，为了减轻负担，用户可能将密码设置成容易记住的如纯数字或字母等，甚至对各种认证设置相同的密码，或者将复杂密码记录在纸上贴在工作台上，这些做法会降低系统的整体安全性，密码被非法截获的可能性增加，使系统容易被破解或攻击从而造成不必要的损失[3]。对管理员来说，被迫管理越来越多的身份，对用户职责权限的维护也需要花费大量的时间进行调整。因此云环境下建立跨域的单点登录系统，实现一处登录，在权限范围内处处可用，减少安全隐患，减轻用户和管理员的负担成为当前云计算安全研究的热点。
1 现有单点登录系统的模型及其优缺点
单点登录，即SSO(Single Sign-on），是解决用户访问几个系统登录几次的问题，在用户使用的多个系统或服务中，用户在一定时间内只需要一套认证方式就能够对这些系统或服务进行权限内的访问。登录一次就可使用经认证的所有系统甚至实现跨域认证。
目前实现单点登录的模型主要有网关模型、代理模型、和令牌模型[4]等3种。网关模型由客户端、网关和应用服务器组成。网关连接着客户端和应用服务器，它是客户端访问服务器的关卡。实现单点登录的关键是在网关上配置身份认证模块，对原有系统不需进行大的修改，但它的安全性和效率受到极大的考验。不适合大规模用户认证，且受到攻击时易危及到服务器的安全。代理模型由客户端、代理软件和应用服务器组成。代理软件的作用就是为不同的应用程序进行身份认证，在客户端和服务器之间充当翻译的作用。它可以安装在客户端或服务器上，这种方式不需要对应用服务进行改动，具有良好的可扩充性。但因为它要求每一个服务配置一个代理软件，开发的难度和工作量比较大，通用性较差。令牌模型由客户端、认证服务器和应用服务器组成。认证服务器提供一个公共和独立的“第三方”，方便扩展，适合大规模的用户认证，但这种方案必须改造旧的应用系统，需付出极大的代价。通常是在单域环境下通过门户实现单点登录，利用cookie的形式或通过隐藏字段中的加密值来提供安全令牌，这种方式限制了跨域登录。对应三种模型，目前有一些比较成熟的单点登录解决方案，如微软的Passport、IBM的Web Sphere Portal Server、CAS，但它们有着不同的侧重点，适合于不同的平台与架构，系统比较复杂，缺乏灵活性，而且价格和学习成本都比较高，不太适合小中型企业的部署和应用[5]。本文在比较现有的3种单点登录模型优缺点的基础上，针对云环境的特点，尝试建立一种云环境下的跨域单点登录系统。
2 基于云环境的单点登录方案
云环境的主要应用模式是SaaS，客户通过Web的方式访问云资源。目前云环境单点登录主要综合上述3种模型的优势，使用云资源提供者的专有API建立个人链接，访问时将相同的用户登录凭证发送给每个应用程序。但随着云资源供应商的增多，将给用户带来维护和管理上的不便。本方案采用认证群，认证群实现与各种SaaS应用的后端整合，用户端只需进行Web Service包装，这样用户端可以做最少的修改，有较好的兼容性和扩展性。
2.1 云环境单点登录的基本功能
从前面可知，比较有效的单点登录必须能保证一个实体（包括用户和资源，以下均以用户替代）通过了一次身份认证后，在一段合理的时间内访问受信的其他资源时，不再需要进行身份验证，同时享有原来的权限。因此单点登录的基本功能应包括统一身份认证、原有系统到新系统的身份映射和统一用户管理，在此基础上实现跨域身份联合认证，并提供身份认证的安全性管理[6,7]。
(1）统一身份认证。云环境的用户为完成某一任务经常需要调用内部和外部的多个资源，这些资源可能跨平台异构、跨多个域，访问时会出现跨越多个信任域带来的跨域服务的联合单点登录验证，但是不能要求每个服务提供者都直接参与认证过程。因此，统一身份认证需要考虑跨域、联合身份认证、委托代理、云服务资源及用户数量的无限扩展性等情况，就可能存在多个认证系统及第三方做身份认证的联合管理，将这些认证系统构成认证群。为方便认证系统间的通信，可以设置一个跨域控制器，同时设置票据授权服务器进一步减轻云服务提供者的负担。控制器负责将请求重定向到对应的域认证服务，票据授权服务器生成云服务对应的票据。所有云服务要共享一个身份认证系统，也就是我们常说的统一认证系统，这是单点登录的前提之一。统一身份认证为云服务提供统一的用户管理平台和身份认证服务，使用户管理与老系统实现无缝对接，实现透明地访问所有授权的资源。
(2）原系统到新系统的身份映射。为了使系统做最小的更改，保留访问原有资源的登录账号和密码及其权限，本方案采用如下方式：在统一身份认证中心创建一个统一登录用户名，并通过身份映射实现该用户名与用户原有各应用的用户名进行映射，形成对应关系。这样，用户登录统一身份认证完成认证后，系统利用身份映射功能就可以访问云端相应的云服务。
(3）统一用户管理。访问控制是安全策略的基础，通过对用户的授权保证资源不被非法访问，如在用户职责发生变更或离开现有组织时，相关系统的管理员都要花费大量的时间修改其账户属性或者删除用户。单点登录系统中的统一用户管理只要向相关的应用程序发出修改或删除账户的命令即可。新的应用系统加入时，可以直接使用统一认证系统，不必再向以前那样建立自己的认证系统。大大减少了管理员的工作量，同时也避免了遗漏等造成权限滥用的出错问题。
2.2 云计算单点登录的原理及模型
随着云计算应用的逐步深入，各公司各机构都会构建自己的共享资源，并且拥有自己的用户，为了保护云服务形成了各自的信任域。用户通过本地认证服务器的认证可以访问域内相应的资源，用户访问其他域的资源时就存在跨域认证的问题。
为实现跨域、跨平台的联合身份认证，与原系统无缝对接，还要使原有系统尽可能只做最小的改动。采用统一身份认证，用户信息集中管理的方式[8]。原有的系统采用Web Service技术构建验证服务替代原来的用户认证模块，并按照SOAP协议的要求封装报文，以便能快速地与其他应用系统对接。认证系统之间通过标准的通信协议互换认证信息[9,10]。模型的具体结构如图1所示。
图1中，票据授权服务器（Ticket-Granting-Sever,TGS）接受用户访问特定资源的请求，负责生成访问该资源的票据（Ticket）。用户使用这个票据，不需要再次认证就可以直接访问授权的云服务；认证系统群（Authentication-System-Group,ASG）负责用户认证，产生访问TGS的票据，完成安全可靠的认证。用户信息库主要包括用户表，云服务表，用户与云服务表，cookie-ticket表等。原有系统中云服务提供者承担用户的认证和授权，随着服务数量和用户数量的增加，服务提供者的压力将呈非线性增加。为减轻服务提供者参与用户进行认证和授权的负担，构建多个身份认证系统构成认证系统群提供集中认证服务，通过身份映射实现统一登录用户与原有用户的对应，并将对应结果存储在用户信息库中。这样可降低云服务提供者的用户管理负担和整个系统的复杂性。
当用户向云服务发送访问请求时，首先会被重定向到认证中心查看用户是否完成了统一登录，如果是第一次登录，需要认证服务器进行统一身份认证；如果用户已经成功登录，会得到登录票据，向TGS请求该用户的认证信息，TGS从用户信息库中提取该用户对应云服务的访问用户名，并返回客户端，用户使用这个用户名登录云服务，并根据权限访问相应的资源。为了保证认证信息在传递过程中的安全，防止票据在传输过程中被截取并篡改，可以对用户信息、生成的票据及其校验信息进行加密，针对实际情况可以采用AES加密用户信息及生成的票据，采用SHA-1算法加密校验信息[11]。单点登录的具体流程及部分关键代码如下[12,13]:
(1）云客户端向云服务1发送访问请求时，如果是第一次登录，会被重定向到统一登录页面，使用ASG提供的账号信息向ASG发送认证请求，跨域控制器将请求转到域内认证服务器AS，访问用户信息库进行统一身份认证，转入（2）；否则，已经通过认证并在有效期内，则直接访问云服务1。
认证函数执行后返回ticket1和用户要访问的应用app1。
(2)ASG成功认证后，向云客户端返回访问TGS的票据Ticket1和与TGS通信的会话密钥。
(3）云客户端使用Ticket1和相关请求信息，经会话密钥加密，向TGS请求访问云资源的票据。
(4)TGS查询用户信息库，并根据授权信息，确认请求合法后，根据授权信息生成相应的访问云服务的票据Ticket2，向云客户端发送Ticket2和与云服务通信的会话密钥。
(5）云客户端使用Ticket2和相关请求信息，经会话密钥加密，向云服务发送访问请求。
(6）云端收到访问请求后，使用通信密钥解密，提取信息中的用户ID、要访问的服务ID和相应的授权信息，确认请求的合法性后，向客户端发送允许访问的响应，并授予相应的访问权限。否则拒绝用户访问请求。
(7）当相同的用户访问云服务2时，将请求重定向到ASG，用户保存的Ticket1将被认证，此次不需要输入用户名和密码，重复（3）后面的步骤即可完成单点登录。
3 结语
单点登录系统方案研究 篇3
关键词：单点登录；统一认证；LDAP
中图分类号：TP311.52文献标识码：A文章编号：1006-8937（2012）05-0073-02
随着企业发展，企业的信息化建设越来越受到企业重视，公司内部都有了自己的办公自动化系统及专业应用系统，如ERP、Oracle、MAXIMO、Lotus Notes等。
部署这些应用面临双重的安全挑战。首先，必须保证只有合法的用户才能访问相应的应用资源。其次，实施安全保护措施时应尽量避免增加用户的负担。随着业务系统的增加，每个用户需要记住多个口令，访问不同的应用系统采用不同的口令。这虽然能够保证用户对应用资源的合法访问，但增加了用户的负担。一方面，为了方便记忆，用户会采用简单的口令或将口令记录下来，这大大降低了应用系统的安全性；另一方面，用户每访问一个应用资源都需要登录一次，这大大降低了工作效率。
目前的首要问题就是：将各个独立的系统进行归纳整理，并建立一个统一的认证平台，使用户在一套用户名口令下根据其权限，就可以访问各个系统的所有数据。
采用SSO单点登陆技术（Single Sign On）可以解决统一认证的需求：将WEB应用系统，Notes应用系统，各专业应用系统进行统一认证，提高信息系统的易用性、安全性、稳定性；在此基础上进一步实现企业用户高速协同办公和企业知识管理功能。
1单点登录（SSO）方案
SSO就是通过一次登录自动访问所有授权的应用系统，从而提高整体安全性，而且用户无需记录多种登录过程、ID或口令。
目前单点登录技术主要分为两类，分别为基于网关SSO技术方案和基于代理SSO技术方案（即前置代理、后置代理）。
1.1基于网关SSO方案（前置代理）
在这种方案中，所有的应用服务器都需要放在被网关隔离的受信网段里。当用户需要访问网关后面的应用服务器时，首先需要通过网关连接的用户数据库进行认证，认证通过后网关自动将用户身份传递到要访问的目标应用服务器进行认证，经应用服务器认证通过后，用户通过网关对应用系统进行后续的访问。 网关负责将用户的帐户信息传递到访问的目标应用服务器，自动实现从客户到服务器的认证转换为服务器到服务器的认证，同时负责认证结束后客户与目标服务器之间的数据传输工作。
1.2基于代理SSO方案（后置代理）
在基于代理的技术方案中，每个应用服务器中都需要安装一个代理程序完成用户的身份认证工作。当用户访问目标应用服务器时，代理程序向SSO服务器询问该用户是否已经登录，如果是，则代理程序从SSO服务器中取得该用户的用户信息自动登录该应用系统，登录成功后，用户直接访问该目标服务器。如果未曾登录过任何应用服务器，则该应用要求用户进行身份认证，认证结束后，代理程序将认证结果发送给SSO服务器。
1.3方案论证分析
基于网关SSO方案对应用系统基本不做任何改变，可容易实现用户对应用系统的资料加密传输，实施和维护相对简单，一旦出现故障，系统复原相对简单。但对应用系统的身份认证和访问都需要经过网关，大用户量访问时，需考虑效率问题。
基于代理SSO方案用户统一认证后，可直接访问应用系统，访问效率较高，但需要针对每个应用系提供相对应的代理插件。
通过以上对比分析，对单点登录系统的功能进行如下说明：
①所有应用系统共享一个身份认证系统。统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。
②所有应用系统能够识别和提取ticket信息。要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。
③单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中。事实上，只要统一认证系统，统一ticket的产生和效验，无论用户信息存储在什么地方，都能实现单点登录。
④统一的认证系统并不是说只有单个的认证服务器，整个系统可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。认证服务器 之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。
⑤单点登录系统要满足即插即用、高可扩展性、应用无关性、满足企业级应用的需求、用户认证信息多样化的需要。
2单点登录系统实施效益
①风险最小化。周密的流程设计和测试演练，可行的安全、易用的网络环境，最大限度的降低突发性灾难对业务环境的影响
②改善性能。通过全面而个性化的系统配置和单点登录的部署，企业业务系统更加安全、快捷、方便。
③增加灵活性。提供后期的关键业务单点登录集成，新业务系统的单点登录集成建议方案和实施方案服务，保证企业的信息化建设可持续的发展。并且提供包括快速响应，及时修复，安全规则审计等针对性的服务支持。
3结语
通过实施建立企业级的单点登录系统和安全防护系统，为企业用户提供统一的信息资源认证访问入口，建立统一的、基于角色的和个性化的信息访问、集成平台；通过实施单点登录功能，使用户只需一次登录就可以根据相关的规则去访问不同的应用系统，提高信息系统的易用性、安全性、稳定性；在此基础上进一步实现企业用户高速协同办公和企业知识管理功能。
参考文献：
[1] 胡毅时,怀进鹏.基于Web服务的单点登录系统的研究与
实现[J].北京航空航天大学学报,2004,(3).
[2］ 李兰友,杨晓光.VisualC#.NET程序设计[M].北京:清华大
学出版社,2004.
[3］ 杜亮.亲密接触ASP.NET[M].北京:清华大学出版社,2002.
单点登录实现方案心得 篇4
一、引言
至于什么是单点登录，举个例子，如果你登录了msn messenger，访问hotmail邮件就不用在此登录。
一般单点登录都需要有一个独立的登录站点,一般具有独立的域名，专门的进行注册，登录，注销等操作
我们为了讨论方便，把这个登录站点叫做站点P，设其Url为http://passport.abc.com，需要提供服务的站点设为A和B，跨站点单点登录是指你在A网站进行登录后，使用B网站的服务就不需要再登录
从技术角度讲单点登录分为： 跨子域单点登录 完全跨单点域登录
二、跨子域单点登录
所谓跨子域登录，A，B站点和P站点位于同一个域下面，比如A站点为http://blog.yizhu2000.com B站点为 http://forum.abc.com,他们和登录站点P的关系可以看到，都是属于同一个父域，yizhu2000.com,不同的是子域不同，一个为blog，一个为forum，一个是passport 我们先看看最常用的非跨站点普通登录的情况，一般登录验证通过后，一般会将你的用户名和一些用户信息，通过某一密钥进行加密，写在本地，也就是一个加密的cookie，我们把这个cookie叫做--票（ticket）。
需要判断用户是否登录的页面，需要读取这个ticket，并从其中解密出用户信息，如果ticket不存在，或者无法解密，意味着用户没有登录，或 者登录信息不正确，这时就要跳转到登录页面进行登录，在这里加密的作用有两个，一是防止用户信息被不怀好意者看到，二是保证ticket不会被伪造，后者 其实更为重要，加密后，各个应用需要采用与加密同样的密钥进行解密，如果不知道密钥，就不能伪造出ticket，（注：加密和解密的密钥有可能不同，取决于采用什么加密算法，如果是对称加密，则为同一密钥，如果是非对称，就不同了，一般用私钥加密，公钥解密，但是无论怎样，密钥都只有内部知道，这样伪造者既无法伪造也无法解密ticket）跨子域的单点登录，和上述普通登录的过程没有什么不同，唯一不同的是写cookie时，由于登录站点P和应用A处于不同的子域，P站写入的 cookie的域为passport.yizhu2000.net，而A站点为forum.yizhu2000.net，A在判断用户登录时无法读到P站 点的ticket 解决方法非常简单，当Login完成后P站点写ticket的时候，只需把cookie的域设为他们共同的父域，yizhu2000.net就可以了：cookie.domain=“yizhu2000.net”，A站点自然就可以读到这个ticket了 ASP。Net的form验证本身实现了这个机制，大家可以参考http://blog.csdn.net/octverve/archive/2007/09/22/1796338.aspx ASP.NET身份验证信息跨域共享状态
在ASP.NET 2.0 中只需修改web.config文件即可，修改方法如下:
domain指定了cookie保存的域，只要保存的是 abc.com形式或者.abc.com的形式，那么其二级域名都可以共享此cookie。
此外，web.config标签中的
三、完全跨单点域登录
完全跨域登录，是指A，B站点和P站点没有共同的父域，比如A站点为forum.yizhu1999.net,B站点为blog.yizhu1998.net，大家可以参考微软旗下的几个站点,这两个站点就没有共同的父域，而仍然可以共用登录，怎样才能实现呢？请参考下图，由于这种情况ticket比较复杂，我们暂时把P站点创建的的ticket叫做P-ticket，而A站点创建的ticket叫A-ticket，B的为B-ticket
由于站点A（forum.yizhu1999.com）不能读取到由站点P（passport.yizhu2000.com）创建的加密 ticket，所以当用户访问A站点上需要登录才能访问的资源时，A站点会首先查看是否有A-ticket，如果没有，证明用户没有在A站点登录过，不过 并不保证用户没有在B站点登录，（重复一下，既然是单点登录，当然无论你在A，B任意一个站点登录过，另外一个站点都要可以访问），请求会被重定向到p站 点的验证页面，验证页面读取P-ticket，如果没有，或者解密不成功，就需要重定向登录页面，登录页面完成登录后，写一个加密cookie，也就是 P-ticket，并且重定向到A站点的登录处理页，并把加密的用户信息作为参数传递给这个页面，这个页面接收登录页的用户信息，解密后也要写一个 cookie，也就是A-ticket，今后用户再次访问A站点上需要登录权限才能访问的资源时，只需要检查这个A-cookie是否存在就可以了 当用户访问B站点时，会重复上面的过程，监测到没有B-ticket，就会重定向到P站点的验证页面，去检查P-ticket，如果没有，就登录，有则返回B的登录处理页面写B-ticket
注销的时候需要删除P-ticket和A-ticket
怎么删除cookie：本来以为这个不是问题，不过还是有朋友问道，简单的说其实是创建一个和你要删除的cookie同名的cookie，并把 cookie的expire设为当前时间之前的某个时间，不过在跨子域的删除cookie时有一点要注意：必须要把cookie的域设置为父域，在本文中 为yizhu2000.com 为了保证各个环节的传输的安全性，最好使用https连接
单点登录系统方案 篇5
随着信息技术和网络的发展,企业信息化建设已经进入了快速发展的阶段。目前,大多数组织内部存在着大量不同的应用系统,如人事系统、办公系统、财务系统及各种对内对外的网站。为了实现对所管理资源的访问控制,大部分系统都采用基于用户名/口令的认证方式,只有被授权的用户才能访问受控资源。每个应用系统都拥有独立的身份认证机制,在进入不同系统时都要重新提交用户名和口令来通过系统的认证,这种分散式用户身份认证机制会导致以下后果:1)用户需要设置大量的用户名和密码,容易混淆。2)用户为了方便,往往会选择简单信息作为口令或者设置相同的口令,这样将会带来巨大的安全隐患。3)对管理者而言,需要创建多个用户数据库,管理繁琐。
鉴于此,单点登录(Single Sign-On,SSO)技术应运而生。它是一套身份认证机制,用来实施在多个独立的应用系统中,用户只需要登录一次就可以访问所有相互信任的Web应用系统,系统间切换时无需再次登录认证,即“一次登录,多方认证”。单点登录系统把原来分散的用户管理集中起来,各系统之间依靠相互信赖的关系来进行用户身份的自动认证。由于用户的信息是集中保存和管理的,管理员只需在一个统一的用户信息数据库中添加、删除用户账号,不必在多个系统中分别设置用户信息数据库,从而避免了应用系统的重复开发和数据同步更新问题,便于系统之间的资源共享,增强了用户体验。该文简述了Cookie的组成和跨域使用方法,提出了一种方便有效的单点登录解决方案,它采用集中式架构,以跨域Cookie共享为核心来完成用户的登录认证。
2 Cookie概述
2.1 Cookie的定义与功能
Cookie是当用户浏览网站时,服务器发送给浏览器的纯文本信息,它保存在客户机上的一个小文本文件,记录了用户ID、密码、浏览过的网页、停留的时间等信息,用户以后访问同一个Web服务器时浏览器会把它们原样发送给服务器。通过让服务器读取它原先保存到客户端的信息,网站能够为浏览者提供一系列的方便服务,如在线交易过程中标识用户身份、安全要求不高的场合避免用户重复输入名字和密码、门户网站的主页定制、有针对性地投放广告等等。目前,Cookie已广泛应用于Web应用中,如Microsoft的Passport单点登录服务就是借助于Cookie完成的。
2.2 Cookie的组成和使用
Cookie的基本格式如下:
Cookie由变量名和值组成,如"Name=VALUE",Name是该Cookie的名称,VALUE是该Cookie的值。其属性里既有标准的Cookie属性,也可以有用户自定义属性,属性中变量也是用“变量=值”形式来保存。其中各项以“,”分开。
Cookie具有以下几种属性:
1)Expires属性:此属性用来给Cookie设置一个期限,在期限内只要打开网页就可以调用被保存的Cookie,如果过了此期限Cookie就自动被删除。如:设定Cookie的有效期到2010年1月1日,到时将自动删除。如果一个Cookie没有设定有效期,则其生命周期从打开浏览器开始,到关闭浏览器结束,每次运行后生命周期将结束,下次运行将重新开始。
2)Domain属性:这个属性定义了Cookie传送数据的唯一性,即只有来自这个域的页面才可以使用Cookie中的信息。缺省时,默认属性为该Web服务器的域名。
3)Path属性:Path定义了Web服务器上哪些路径下的页面可获取服务器设置的Cookie。如果Path属性的值为“/”,则Web服务器上所有的WWW资源均可读取该Cookie。缺省时,Path的属性值为Web服务器传给浏览器的资源的路径名。借助对Domain和Path两个变量的设置,即可有效地控制Cookie文件被访问的范围。
4)Secure属性:指定Cookie能否被用户读取。
5)Haskeys属性:如果所请求的Cookie是一个具有多个键值的Cookie字典,则返回True,它是一个只读属性。
当用户用浏览器首次访问某Web站点(Web服务器)时,服务器端在响应(Response)中创建一个Cookie,并将其写入访问者的计算机。
当用户再次访问此Web站点时,浏览器在它的请求(Request)中包含这个已经创建的Cookie,并且将它返回至服务器,从而完成浏览器的认证。
2.3 Cookie的跨域使用
Cookie分为第一方Cookie和第三方Cookie。第一方Cookie,又叫Session Cookie,是指来自或发送到当前正在浏览的网站的Cookie。第三方Cookie,又叫本地Cookie,是指来自或发送到当前正在浏览的网站以外的网站的Cookie。
在默认安全级别下,IE要求iframe、img等标签只发送Session Cookie,拦截本地Cookie发送。如果这些标签跨域引用一个页面时返回的HTTP响应头中包含Cookie,那么IE无法正常存取HTTP响应中的Cookie。例如,有www.a.com与www.b.com两个域(简称A域与B域)。在B域有一个页面test.html,包含指向A域的iframe:,A域中的test php是一个对A域设置Cookie的页面。当请求http://www.b.com/test.html时,iframe跨域请求www.a.com/test.php,test.php会尝试Setcookie第一次请求,此时浏览器接收到一个Cookie。如果设置Cookie成功,IE再次请求该页面时,由于跨域限制,iframe无法正常发送接收到的Cookie。
为解决Cookie的跨域访问问题,需要应用P3P技术。P3P(Platform for Privacy Preferences)是万维网联盟(W3C)公布的一项隐私保护推荐标准,旨在为网上冲浪的Internet用户提供隐私保护。访问支持P3P的网站的用户有权查看站点隐私策略,然后决定是否接受Cookie或是否使用该网站。
在响应头中设置P3P Header可以允许跨域访问隐私数据,从而可以跨域设置Cookie。修改上文中的www.a.com/test.php添加。再次访问http://www.b.com/test.html时,IE就可以成功收发A域的Cookie。
3 系统设计
3.1 系统构成
1)Web浏览器。用户通过IE等Web浏览器发送资源请求并接收应用服务器的响应。当用户登录时,IE提交的表单里含有用户名和密码,登录成功后浏览器接收服务器传回的Cookie保存在本地客户端机器上,并在其后的每次请求中携带Cookie信息用以身份认证。
2)应用服务器。判断用户是否登录并向用户提供各种资源,包括网页、文件、图片等。当用户请求资源时,应用服务器负责检查用户请求中是否携带Cookie信息、携带的信息是否有效。当用户登录时,应用服务器负责将用户信息转发给认证中心服务器完成认证。
3)认证中心服务器。它负责存储所有应用程序的用户信息,利用数据库信息验证用户提交的用户名和口令。同时,认证中心服务器还负责存储所有应用服务器的信息,用以获取可以生成某一个应用的Cookie的链接。认证服务的安全性也通过认证中心存储的密钥来保证。
3.2 基于Cookie的认证过程
基于Cookie的跨域单点登录系统的认证主要包括两部分的交互过程。一是Web浏览器和应用服务器的交互,二是应用服务器和认证中心服务器的交互,Web浏览器不和认证中心服务器直接交互。图1表示的是系统的认证过程:用户首先在未登录的状态下访问应用1的资源,登录成功后访问应用2的资源。实线代表的是用户(Web浏览器)和应用服务器的交互过程,虚线代表的是应用服务器和认证中心服务器的交互过程。其中应用1和应用2位于不同的域中。
流程图中的主要过程的描述如下:
1)用户通过浏览器请求应用1的保护资源,如某一个网页。
2)应用1服务器接收到请求后,分析请求的Header,检查其中的Cookie信息。
3)用户第一次访问应用1,所以请求中无Cookie信息,应用1重定向到登录页面,返回给浏览器。
4)用户在浏览器登录页面填写完用户名和密码后提交表单,应用1服务器接收到表单后,提取出用户名和口令信息。
5)应用1将用户名和口令及应用1信息(如应用ID,时间戳、交互类型等)加密后提交到认证中心服务器。
6)认证中心服务器接收到应用1的请求后,利用解密密钥将用户信息和应用信息提取出来,然后根据数据库中存储的用户信息判断用户名和密码在应用1中是否有效。认证成功后,认证中心服务器完成第二个功能:根据存储的应用1和应用2的信息,为两个应用各生成一个特殊的链接地址。如果用户在浏览器中访问这个链接,相应的应用服务器会在响应中添加Cookie信息供浏览器保存和使用。
7)认证服务器将生成的两个链接地址分别添加到的字符串后返回给应用1服务器。
8)应用1将含有链接地址的