单点登录模型

单点登录模型（精选7篇）

单点登录模型 篇1

1. 引言

目前单点登录系统还处在一个发展的阶段, 还存在很多的安全效率问题没有得到很好的解决。尤其是, 在本文对传统的单点登录系统模型进行改进之后, 某些安全问题变的更加突出。所以必须加强对单点登录系统安全性和效率的研究, 针对面临的安全效率威胁选择合适的技术措施解决。

2. 设计目标

以下设计目标和应用要求应该是本文所研究的单点登录系统应该满足的。

(1) 统一身份认证。在已经进行一次登录的情况下, 用户无需重复提交身份信息就可以浏览任何其可访问的资源, 而且可实现具有权限的模糊身份访问某些资源, 保护用户的隐私信息。

(2) 同一用户管理, 便于系统管理员和用户的使用。

(3) 为了使用统一认证服务认证每个系统基于Web服务应用集成的实施, 需要支持Web服务框架。

(4) 高效率登录。用户在登录系统的时候, 必须把认证所需要的延迟控制在一定的范围之内。

(5) 可配置的身份认证模块。进行身份认证的模块, 必须能够根据用户的需求进行配置。

(6) 高度的安全性。由于单点登录系统本身的功能性质, 要求系统必须保证用户信息在传输的过程中不被泄露。

3. 整体框架设计

基于SAML的单点登录模型由三个实体组成, 分别是主体, 源站点和目标站点。这三个实体都是抽象的概念, 在设计基于上述改进模型的单点登录系统时, 本文将模型中的主体, 源站点和目标站点分别映射为客户端, 身份认证服务器和目标服务端这三个站点。

以下是单点登录系统各个组成部分的功能描述:

(1) 消息安全处理模块

安全处理模块支持三类功能:保证消息完整性和验证消息源的XML签名;确保消息机密性的XML加密和解密;防止重放共计的附加标识符信息。三个功能共同确保SOAP消息的安全性。

(2) 传输模块

将XML信息包装成SOAP消息并发送, 和接受SOAP消息并从中提取XML消息是传输模块的主要功能。

(3) 客户端

接收用户输入信息, 发出经过安全处理的请求信息生成SAML请求并等待响应是客户端的主要功能, 使用SAML令牌访问目标服务, 接受调用结果。

(4) 身份认证服务器

根据请求信息发放基于数字签名的身份验证是身份认证服务器的主要功能, 生成SAML响应, 并返回给客户端经过加密的安全SAML令牌。

4. 系统的运行流程

系统的框架结构、主要组成部分以及数据流走向如上面的系统框架图所示, 下面是详细的描述。

(1) 用户第一次使用该系统时需要在客户端输入登录信息, 客户端生成SAML请求。

(2) 消息安全处理模块根据密钥A将SAML请求进行正向的签名、加密、添加标识符等处理并打包成SOAP信息, 传输模块将此信息发给身份认证服务端并等待回应。

(3) 监听和接收请求信息并传递该信息至身份认证服务器的安全处理模块是传输模块的主要功能, 反向处理 (解密、验证标识符以及数字签名以确定该请求的合法性) 信息后得到登录信息。

(4) 认证服务器的身份认证模块根据提取出的用户登录信息查询LDAP目录服务器, 对用户进行身份认证, 并生成SAML身份认证声明和属性声明。

(5) 身份认证服务器的授权模块查询LDAP目录服务器, 对该用户进行授权, 并生成SAML授权声明。

(6) 安全处理模块接收并安全处理上两步生成的SAML声明, 通过利用目标站点和身份认证服务器共同认证的密钥B加密和签名之后生成SAML令牌, 以确保令牌中的信息只有合法的目标站点才可获取。

(7) 为了保证令牌在传输过程中的安全性, 需要再次利用密钥A正向处理 (加密及签名) SAML令牌并将打包成的SOAP消息返回给客户端,

(8) 等待并接收身份认证服务器返回的相应并传递至安全处理模块是客户端传输模块的主要功能, 反向处理 (解密、数字签名的验证) 消息。用户可以使用可以安全访问目标站点的SAML令牌, 但其中的信息为未知。

(9) 客户端在得到目标站点的URL、服务名称及参数之后利用身份认证中心发布的密钥K加密SAML令牌并发给目标站点。

(10) 该消息需要经过目标站点的两种验证。第一是利用密钥K解密该信息并验证标识符, 以确认该消息来源于认证中心认证过的用户且并未被重放。第二就是通过安全处理模块利用密钥B解密和验证签名SAML令牌, 以确保该令牌是身份认证服务器颁发, 间接地验证信息请求者的合法性而免去向身份认证中心重复验证。

(11) 目标站点需要依据SAML规范解析原始SAML令牌中的声明, 得到SAML权威作为声明信息。

(12) 目标站点根据声明中的信息判断该用户的授权是否足以访问它申请的信息。

(13) 根据结果提供相应的服务。

一次单点登录的全过程至此结束。用户还可以凭借安全的SAML令牌访问其他的站点。这个登录过程都是单点登录系统自动实施的, 不需要用户参与。

5. 结束语

单点登录系统的高效、灵活、安全的实现十分复杂, 本研究只是优化了目前严重影响单点登录系统性能的一些地方, 系统整体上的运行效率和安全效率还有待于提高。

参考文献

[1]钟迅科.基于SAML实现Web服务的单点登录[J].现代计算机, 2004, (185) :32-36.

[2]余荣, 刘明华.基于SAML实现Webservice的单点登录[J].计算机与现代化, 2005, (12) :81-83

单点登录模型 篇2

随着办公自动化的发展, 越来越多的学校开始采用网上办公, 出现了很多的校园网应用, 比如教务管理系统、网络综合平台、个人信息门户管理系统等。这些应用系统往往是不同公司基于不同的平台开发的, 使得每个教师不得不记住多个用户名和密码才能登录到不同的管理系统, 以完成对应的教学和 日常工作 , 降低了用 户体验。 单点登录 (SingleSign-on, 简称SSO) 是指用户在访问多个系统和多种受限资源时, 只需进行一次登录和身份验证, 避免了反复输入大量的用户名和密码, 提升了用户体验。Kerberos协议为分布式网络环境中基于Client/Server的网络应 用提供了 一个统一 身份验证和 单点登录 方案 , 但由于HTTP协议的无 状态性 ,Kerberos协议无法直接应用于Browse/Server (B/S) 结构下的万维网 应用中。 安全断言 标记语言 (SAML) 是当前另 一个单点登录实现的 方案 , 它是一个 基于XML的框架 , 用于交换有关主体的验证和授权断言信息。SAML模型简单、通用,但SAML本身并没 有规定实 体间交换 信息的安 全协议 , 因此, SAML需要和其他的安全协议或者技术结合使用提供安全的单点登录。

2 两种单点登录方案的分析

Kerberos是由美国麻省理工学院 (MIT) 的Athena项目小组提出的基于可信赖的第三方的高效验证机制。它的体系结构由KDC (Key Distribution Center,简称KDC)、Kerberos应用服务器、Kerberos客户端3个部分组成。当用户要申请需要Kerberos验证的网络服务时 , 首先由KDC提供的验证服务 (Authentication Service, 简称AS) 对用户的身份进行初始验证 , 如果验证通 过 , 则发放给 用户一个 称为TGT (Ticket GrantingTicket) 的票据 , 用户凭借该票据访问KDC提供的票据授权服务 (Ticket Granting Service, 简称TGS), 从而获得访问应用服务器所需 的服务票 据ST (Service Ticket)。Kerberos协议Kerberos采用对称密钥体制对信息进行加密 , 通过提供一个集中的验证服务器来负责用户对服务器的验证和服务器对用户的验证, 为分布式网络环境中传统的基于C/S的网络应用提供了一个较好的统一身份验证和单点登录方案, 并且得到了广泛的应用。

Kerberos协议的体系结构和运行环境要求在客户端进行加解密计算, 并且要求客户端维护与验证服务器和应用服务器的交互状 态。万维 网环境中 的网络应 用依靠HTTP (HTTPS)来承载数据量, 而HTTP是一个不维护状态的协议, 并且要保持客户端运行环境 (万维网浏览器) 的简单易用性, 使得Kerberos协议在万 维网环境 中的应用 需要加以 改进。同 时Kerberos将验证和授权集于一身 , 由TGS对用户进行授权 , 决定是否发放ST, 这种方式限制了所有的服务提供方都要采用一样的授权模型。

SAML主要是为了解决万维网服务安全体系中的身份验证多次使用的问题, 能为用户提供跨越异种网络和平台的单点登录的验证和授权。SAML是一个基于XML的框架, 允许不同的机构安全地在他们的用户之间交换验证、授权和profile信息 , 而不用考 虑他们所 使用的安 全系统和 应用平台 。SAML规范由断言 ( 验证断言、授权决策断言、 属性断言 ) 、请求/响应协议、绑定和概要这4个部分组成。基于SAML的单点登录框架中通常由主体、身份提供者 (Identity Providers,简称IDP)、服务提供者 (Service Providers,简称SP) 3个实体组成。并提供了Browser/Artifact和Browser/POST两种单点登录模型。

SAML只是定义了各种声明的文档结构 , 本身并没有安全机制保证各种断言交换过程中的安全性, 容易遭受到中间人攻击、重放攻击、信息泄漏攻击等一些恶意的攻 击。因此 ,SAML需要和其他的安全协议或者技术结合使用提供安全的单点登录。

将这两种单点登录方案进行融合, 取长补短, 采用Kerberos安全协议的基本思想 , 并对其进行改进和简化 , 其适用于B/S模式的校园网环境, 同时将SAML进入该模型, 对Kerberos协议中的服务票据令牌进行改进 , 使用SAML完成跨域的真实身份信息的传递, 使校园网中的跨域跨平台的应用之间都可以通过该模型完成单点登录。

3 基于 Kerberos 校园网单点登录模型

3.1 设计思想

(1) 校园网环境下单点登录模型采用B/S结构设计 , 验证服务器、票据授权服务器和服务提供方的万维网应用服务器直接利用万维网重定向技术交换信息。

(2) 校园网环境下单点登录模型采用统一的用户验证功能, 由SSO服务器集中管理用户信息, 负责用户验证。

(3) 校园网环境下单点登录模型将用户验证功能和授权功能进 行分离 , 身份验证 功能由SSO服务器完 成 , 而访问控制 移交给服 务提供方 , 可以完成 细颗粒的 可定制的 授权工作。

(4) 票据授权服务发放的服务票据中包含SAML断言的引用, 此引用只能使用一次, 从而可以防止重放攻击。

(5) 验证服务器和票据授权服务器之间交换的信息使用事先协商好的共享密钥加密, 而票据授权服务器和服务提供方的服务器之间交换的信息使用票据授权服务器发放的会话密钥加密, 会话密钥的发放通过服务提供方的公钥加密以安全方式传输。

(6) 校园网环境下单点登录模型除了能够保证万维网服务的基本安全需求外还能够有效地防止重放攻击、拒绝服务攻击等安全威胁。

3.2 体系结构

单点登录模型的体系结构如图1所示, 模型包括3个系统实体: SSO服务器 (包括验证服务器和票据授权服务器)、服务提供方和用户。

SSO服务器 : 整个体系的核心 , 集中存储管理用户信息、服务提供方站点信息和密钥信息, 为用户和合作的服务提供方提供统一的身份验证和单点登录功能。SSO服务器包括AS和TGS两部分, 其中AS负责对用户进行全局验证, 发放票据授权票据TGT, TGS为成功验证的合法用户生成SAML断言, 产生与服务提供方交换信息所需的会话密钥, 发放访问服务提供方应用服务的服务授权票据ST (包含SAML断言的引用)。AS和TGS之间交换的信息用事先协商好的共享密钥加密。

服务提供方SP: 参与单点登录的服务提供者, 通过万维网站点以万维网方式为用户提供服务。SP通过万维网重定向与SSO服务器交换信息, 完成对用户的验证, 并根据最终取得的用户的SAML断言完成授权工作。它们之间交换的信息使用TGS创建的会话密钥进行加密。

用户: 参与单点登录的合法用户, 使用单点登录功能访问网络的应用和服务。用户端的运行环境为万维网浏览器。

3.3 单点登录流程

用户第一次请求SP的万维网服务 时 , 需要经过4个阶段:

(1) 登录AS, 申请能够获取SP的万维网应用服务授权票据ST的票据授权票据TGT。登录成功后, AS还为用户生成全局会话以支持其他SP的万维网单点登录。

(2) TGS验证用户的TGT后 , 为用户生成SAML断言和SAML断言的一次性引用 , 创建TGS和SP之间交换信息所需要的会话密钥, 发放给用户所申请的万维网应用的服务授权票据ST。

(3) SP验证服务授权票据ST, 向TGS请求SAML断言并缓存到本地, 为用户创建本地会话以支持用户在本站点上持续的万维网单点登录。

(4) SP根据用户的SAML断言结合自身的授权决策机制决定是否为用户提供服务和提供哪些服务。

4 结语

单点登录模型 篇3

随着互联网和云技术的发展,信息的安全保障问题成为很多学者研究的重点,而安全协议是信息安全保障的灵魂［１］,越来越多的学者对安全协议及模型的安全性进行了研究。

用户在浏览网页和应用时,往往需要多次登录,过程繁琐而复杂,用户体验差。单点登录(Single Sign on,缩写SSO)技术解决了这一问题,用户仅需一次登录即可访问多个网站或应用资源。

安全断言标记语言(Security Assertion Makeup Lan- guage,缩写SAML),是结构信息标准化促进组织(OA- SIS)发布的标准。标准中,OASIS规定了一系列SAML协议及消息结构来实现数据交换［２］,在此基础上给出了Web-SSO单点登录模型［３］,解决了一次认证即可访问多处资源的问题。SAML标准被很多厂商支持并应用于产品中,如Google、Internet2等。

1 SAML2.0标准

SAML2.0标准是OASIS自SAML1.0、SAML1.1标准后制定的新标准,OASIS在SAML2.0标准中给出了一系列协议,如断言询问与请求协议、认证请求协议等,并在这些协议的基础上给出了一系列模型,如Web-SSO模型、 联合身份模型等。

SAML2.0标准给出了各协议消息的结构。标准指出,SAML请求与回应消息分别源自两个父消息结构: RequestAbstractType和StatusResponseType。Request-AbstractType是请求父消息结构,包含的项有ID、Ver- sion、IssueInstant、Destination、Consent、<saml:Issuer>、 <ds:Signature>、<Extensions>,其中ID、Version、Is- sueInstant是必须有的项,分别代表请求消息的标识符、版本号和时间点,其它项则根据具体情况可选。StatusRe- sponseType是回应父消息结构,包含的项有ID、InRe- sponseTo、Version、IssueInstant、Destination、Consent、< saml:Issuer>、<ds:Signature>、<Extensions>、<Sta- tus>,其中ID、Version、IssueInstant是必须有的项,分别代表回应消息的标识符、版本号和时间点,其它则是根据具体情况可选的。标准根据这两个父消息结构定义了< AuthnRequest>、<Response>等重要消息结构。

在SAML2.0标准定义的所有消息结构中,最重要的是Assertion消息结构。Assertion是SAML2.0的重要组成部分,OASIS在SAML2.0标准中定义了3种不同的Assertion:1认证:断言主体在特定时间用特定方式被认证;2属性:断言主体与一些属性相关联;3授权决策:断言主体对指定资源的访问请求被同意或拒绝。

2 Web-SSO模型

SAML2.0标准给出了Web环境下进行单点登录的模型,规定了消息传递的3个主体及消息的流程与结构, 实现了一次认证即可访问多个网站资源。标准规定3个主体:用户代理(User Agent,缩写UA)、服务提供者(Service Provider,缩写SP)、认证提供者(Identity Provid- er,缩写IdP)。SAML2.0标准给出了两种单点登录模型: SP起始模型和IdP起始模型,本文研究的是IdP起始模型。IdP起始的Web-SSO模型消息流程如图1所示。

整个消息交换过程分为6步,即6条消息:1向用户发送认证请求:IdP向UA要求认证信息,因此IdP将发送一条credentials request消息给UA,要求UA提供相应的身份信息;2用户提供合法身份信息:UA收到消息1,将向IdP提供合法身份信息,因此UA将根据消息1的要求,发送一条消息credentials response给IdP,若用户提供的是合法身份信息,IdP将在本地为该用户建立一个安全上下文;3用户请求远程资源:UA在IdP上选择一个菜单或链接向IdP请求在SP上的远程资源,因此UA将发送一条消息resource request给IdP,向IdP请求SP上的远程资源,这条消息可以是一条url链接;4断言封装发送:IdP收到消息3后,用户请求的远程资源地址url将被IdP封装在RelayState里,同时IdP将用户的安全上下文封装在SAML2.0标准的<Response> 里,即该<Re- sponse>包含Aseertion断言,然后IdP生成一条消息http response,发送给UA;5断言转发:UA收到消息4后,得到了断言消息,然后发送一条消息http post request给SP,该消息内容和消息4的内容相同,即UA将消息4转发给SP;6资源发送:SP收到消息5,确认用户权限后发送给UA一条消息resource response,即将资源resource发送给UA,最后结束消息交换。

2.1 credentials request消息结构

credentials request消息的作用是IdP向UA发送认证请求。由于这个消息仅仅是一条认证请求,不包含其它内容,故该消息仅包含1个数据项:credentials_request, IdP向UA发送的认证请求。

2.2 credentials response消息结构

credentials response消息的作用是UA向IdP发送合法身份信息,SAML2.0标准中没有给出具体的认证方式,具体的实施方式由厂商决定,可以是用户名/口令等多种认证措施。Google、Sun等厂商在认证方式上已经给出了完整且安全的实施方案,因此本文不将此处的认证方式作为重点,采用常用的安全认证方式即可［４］。故将消息省略为1个数据项:credentials,身份信息。

2.3 resource request消息结构

resource request消息的作用是UA向IdP请求SP上的资源。由于请求的是SP资源而非IdP资源,因此消息必须包含SP上资源的地址,而此条消息将发送给IdP。 此处将发送的是一个url链接,链接的内容是SP上资源地址。该消息包含1个数据项:url,SP上资源的地址。

2.4 http response及http post request消息结构

http response及http post request两条消息完成的功能是:IdP经UA转发给SP一组数据,两条消息的组成是一样的,都是<Response>及UA的资源请求RelayState。 <Response>的父结构为StatusResponseType,它是一个复合结构,包含7个主要数据项:1ID,该消息的标识符; 2Version,SAML版本号;3IssueInstant,产生消息的时间点;4Destination,消息发送的目的地;5<saml:Issuer > ,产生消息的主体;6 <Status>,状态码;7 <saml: Assertion>,断言,一个复合结构,包含安全上下文。其中,ID、Version、IssueInstant、<Status> 是父类结构Sta- tusResponseType所要求的组成部分,<saml:Assertion> 是<Response>重要的组成部分,Destination、<saml:Is- suer>则是根据IdP起始的Web-SSO模型需求选择属性。

由于<saml:Assertion> 是一个复合的数据项,因此又能拆分成7个主要数据项:1ID,该消息的标识符;2 Version,SAML版本号;3IssueInstant,产生消息的时间点;4<Issuer>,产生消息的实体;5 <ds:Signature>, 签名;6<Subject>,状态信息的主体;7 <AuthnState- ment>,状态信息。其中,ID、Version、IssueInstant、<Is- suer>是Assertion结构必须的组成部分,<ds:Signature >是IdP起始的Web-SSO模型所要求的组成部分,< Subject>、< AuthnStatement> 则是根据IdP起始的Web-SSO模型的实际需求选择的属性。

2.5 resource response消息结构

resource response消息即SP发送给UA的资源。由于该消息仅为资源的传送消息,不包含其它内容,故该消息仅包含1个数据项:resource,请求的资源。

3 ProVerif建模

形式化分析验证工具ProVerif由Bruno Blanchet开发,基于符号模型［５］,其输入语言为应用PI演算［６］。由于SAML2.0标准中IdP起始的Web-SSO模型要求Aseer- tion数据项必须加密,且Aseertion数据项是该模型最重要的部分,包含了用户的安全上下文,因此本文利用ProVerif工具对模型进行建模,分析Aseertion数据项的安全性［７］。

3.1参数定义

初始化定义函数,规定函数关系,设置私有共有变量, 最后给定询问语句。由于Aseertion消息有签名,因此需要签名和验证函数,函数的设置和函数关系就在参数定义部分。fun function/1表示声明了一个function函数,而该函数有一个数据项,具体的数据项格式不用给出。equa- tion则用来定义函数之间的关系,一般在定义加密解密、 签名验证函数时需要,相关语句如下:

另外,在初始化定义时,要定义询问语句,query表示定义询问语句,本文设置了两个询问语句:1用attacker: secret语句,表示secret是否会被attacker知道,这个语句可以用来验证断言Assertion的保密性;2ev:B = = > ev:A语句,表示当事件B发生时,事件A肯定已经发生, 这个语句可以用来验证断言的签名,相关语句如下:

3.2三个进程

建模过程建立了3个进程:processA,表示UA进程; processB,表示SP进程;processC,表示IdP进程。3个进程并行发生,通过一共6条消息来完成通信。用in()表示接收消息,out()表示发送消息。

为了完成通信,UA进程一共发送和接收了6条消息:1接收了credentials request,收到了IdP发来的认证请求消息;2接收了http response,收到了IdP发送来的断言消息;3接收了resource response,收到了SP发来的资源消息;4发送了credentials response,向IdP发送了合法的身份信息;5发送了resource request,向IdP发送了请求远程资源的消息;6发送了http post request,向SP转发了从IdP接收的断言消息。SP进程一共发送和接收了2条消息:1接收了http post request,收到了UA转发来的断言消息;2发送了resource response,将资源消息发送给UA。IdP共发送和接收了4条消息:1接收了cre- dentials response,收到了UA发送来的身份信息;2接收了resource request消息,收到了UA发送来的请求远程资源消息;3发送了credentials request,向UA发送身份认证请求;4发送了http response,向UA发送断言消息。

在设置认证性事件语句时,将事件begin(Signature) 设置在消息IdP发送http response消息前,将事件end (b175)设置在SP发送resource response之前,即可验证SP的认证性。设置认证性事件的相关语句如下:

3.3主进程

主进程的作用是让UA、SP、IdP 3个进程并行发生,| 表示进程并行发生,而!表示进程不断循环发生,因此可以保证3个进程同时并行发生［８］。相关语句如下:

process!processA| !processB| !processC

3.4运行结果

将上述应用PI演算语句导入ProVerif,经过运行得到了安全性分析结果。根据运行结果,断言Assertion的保密性和其签名的认证性结果均为true。该结果表明:在基于SAML2.0的IdP起始的Web-SSO模型中,断言As sertion不会被攻击者知道,即具有保密性,且断言Asser tion的签名具有认证性,运行结果如图2所示。

4结语

本文根据SAML2.0标准中给出的IdP起始的Web- SSO模型,将其分为3个主体:UA、SP、IdP,6条消息:cre- dentials request、credentials response、resource request、ht- tp response、http post request、resource response,并对每一步消息进行细化得到消息结构,应用PI演算对该模型建模,并在ProVerif工具中运行该模型的PI演算;分析了SAML2.0标准中最重要的消息结构断言Assertion的安全性,利用询问语句分析了断言Assertion的保密性和认证性,得到其具有保密性及认证性的结论。

摘要：随着互联网的发展,人们对安全协议及模型的安全关注度越来越高。由于SAML2.0标准被越来越多的厂商支持用于单点登录,因此关于其安全性的研究也越来越多。根据SAML2.0标准,针对标准给出的IdP起始的Web-SSO模型对每一步消息结构进行细化,使用形式化分析工具ProVerif对该模型进行建模,分析其安全性。

单点登录模型 篇4

随着Web技术的发展和企业信息化的普及, 用户所使用的不同网络应用和网络服务数量正在不断增加, 在给用户提供方便的同时对用户的身份认证、服务权限管理等的要求也相应地提高。传统的认证机制基于用户名和密码, 每一个系统都有自己的用户信息数据库, 用以验证用户的身份。用户进入每一个应用系统前都需要以该应用系统的账号来登录。随着用户登录系统的增多, 出错的可能性就会增加, 受到非法截获和破坏的可能性也会增大, 系统安全性就会相应降低。而如果用户忘记口令, 不能执行任务, 就需要请求管理员的帮助, 并只能在重新获得口令之前等待, 造成了系统和安全管理资源的开销, 降低了工作效率。

如在某国有大型企业信息服务平台[1]内包含有协同OA系统、一体化财务系统、一体化采购物流系统、e-HR系统、一体化销售系统等互相独立的软件系统, 用户在使用每个应用系统之前都必须按照相应的系统身份进行登录。为解决此类愈见突出的安全和方便性问题, 采用单点登录技术来提高信息服务平台的安全性显得尤为重要。

2 单点登录模型分析

所谓单点登录[2] (Single Sign-on, SSO) 是一种用于方便用户访问网络的技术。无论多么复杂的网络结构和网络应用, 用户只需进行一次登录注册, 即可获得所需访问系统和应用软件的授权, 便可以在网络中自由穿梭, 不必多次输入用户名和口令来确定用户身份;同时, 管理员无需修改或干涉用户登录就能方便地实施希望得到的安全控制。从而可以大大提高系统的安全性, 同时也可以保证用户的电子身份标识在网络上可以安全、高效传递。SSO的核心是应用系统之间的信任传递问题。

该单点登录模型包括四个参与方, 即需要进行身份认证的双方、一个双方都信任的第三方以及终端用户方。其中, 最初发起方为终端用户, 用户已经登录过的应用系统称为客户方 (应用服务器A) , 响应方称为服务器方 (应用服务器B) , 进行统一用户验证和票据发放的一方称为密钥分发中心 (KDC) [3], 即认证服务器, 以及终端用户。

该模型的核心流程是:客户方通过向服务器方递交自己的“票据” (Ticket) 以验证身份, 票据中封装了加密密钥和其他信息, 其中加密解密通过公钥私钥进行加密解密。KDC能够发放的票据有两种:票据授权票据 (TGT) 和服务票据 (ST) 。单点登录时, KDC首先向合法用户发放TGT, 合法用户在访问某一服务时, 利用TGT向KDC申请该服务的ST, 经过客户方和服务器方双端认证后, 建立双方会话 (Session) 。

使用该集中方式的认证体系结构, 用户只需与信任圈中的安全认证系统进行交互以获取用户的身份信息或属性信息。其体系结构如图1所示。

其实现算法如下:

(1) 用户访问协同OA系统时, 如果还没有登录, 就会被重新定向到认证服务器进行登录;

(2) 用户输入登录信息, 认证服务器根据用户提供的登录信息进行身份效验;

(3) 如果通过身份效验, 认证系统就返回给用户一个认证的凭证, 用户可以通过这个凭证访问协同OA系统;

(4) 用户再访问e-HR系统时就会带上这个凭证, 作为自己认证的凭据;

(5) e-HR系统接受到请求后就对凭证进行认证。一种方案是采用自身认证机制对凭证进行认证, 另一种方案是将凭证送到认证系统进行认证。通过检查凭证的合法性, 如果效验通过, 用户就不用再次登录直接访问e-HR系统。

从图1可以看出, 要设计和实现SSO模型必需实现以下核心功能:

(1) 认证服务器的密钥分发和统一认证:通过认证服务器对每个系统分配公钥私钥对, 只有该认证服务器知道密钥对。同时通过它来生成统一认证凭证和实现合法性认证。认证系统主要是将用户的登录信息和用户信息存储系统中的信息相比较, 对用户的登录进行认证;认证成功后, 认证系统应该生成统一的认证凭证, 返还给用户。另外, 认证系统还必须对认证凭证进行效验, 判断其有效性;

(2) 所有应用系统通过认证服务器分配给它的私钥, 能够识别和提取统一的认证凭证信息, 判断其访问用户的合法性。

3 单点登录模型的设计和实现

在系统设计与实现时, 首先需要考虑传输的数据结构, 其次是根据总体架构, 包括以下组成部分的设计:认证服务器的设计、应用服务器客户端认证的设计。

3.1 传输数据结构的设计

在考虑票据[4]传输时, 我们需要考虑双方能相互识别的数据结构, 我们设计的票据数据结构包括票据和票据存根 (Stub) 两部分。票据存根记录用户的登录信息, 而票据只是对票据存根的引用。

票据存根可用数据结构表示为:Ticket_Stub (stubId, userId, sysID, lifeCycleFrom, lifeCycleTo, checkInterval, sessionId) 。其中, stubId表示票据存根编码, UserId是用户编码, sysID为访问的系统标识, lifeCycleFrom、lifeCycleTo分别是票据存根创建时间和结束时间, checkInterval为最长访问时间间隔, sessionId是用户浏览器与需访问Web服务器之间的会话密钥, 每次重建会话时SessionId也随之重新生成。

票据用表达式ES (Sid, Sign (Sid, E-1AS) ) 表示, 其中Sid表示会话密钥, S表示用户需要访问的Web服务器, AS (Authentication Server) 表示认证服务器, Ex表示x的公钥 (x为变元, 可代表S或AS下同) , E-1x表示x的私钥, E (...) 表示使用密钥K对括号中的内容进行加密, Sign (…, K-1x) 表示对括号中的内容使用x的私钥进行签名。

应用服务器和认证服务器之间数据的传输, 通过以上加密后的信息, 在认证服务器进行解密, 然后验证合法性。

3.2 认证服务器的设计

认证服务器可由以下主要模块实现:

(1) 统一认证服务模块:对用户提交的认证信息进行处理, 进行用户合法性检查、时间戳检查, 并根据判断结果决定是否返回TGT票据。具体实现时, 通过CredentialUtil类的checkCredential () 方法进行检测。

(2) 密钥管理模块:负责生成公钥私钥密码对, 定期更新;同时随机生成会话密钥。具体实现时, 通过PasswordGen类的genPair () 和genSessionKey () 方法进行密码生成。

(3) 票据管理模块:对应用服务票据的请求进行处理, 进行加密解密操作, 并将合法的信息传回应用服务器。具体实现时, 通过TicketManager类的composeCredential () 方法进行数据结构的组装, un FoldCredential () 方法进行数据的拆装。

(4) 辅助模块:进行相关的辅助功能, 例如定时处理模块、线程控制模块等。

3.3 客户应用服务器的设计

对于各个应用服务器, 需要检查用户是否已经登陆, 防止非法用户访问。各个Servlet和JSP都是通过URL来提供访问, 当用户访问时, 如果每个Servlet和JSP都去统一认证服务进行检查, 开发的费用非常大。为了降低费用, 我们使用Filter过滤器, 通过Filter机制, 对于每一个应用系统, 在一个集中的点进行身份认证的检查即可。

客户应用服务器的过滤器主要完成两个职责, 一个是检查是否登陆, 并与认证服务进行交互;另一个负责完成客户应用的自动登陆。我们设计的Filter如下:

认证服务过滤器AuthenFilter:通过该过滤器来检查是否已经登陆, 如未登陆, 则与认证服务进行交互, 完成整个登陆过程。如果已经登录, 则开放信息, 允许用户访问。具体实现流程如下:

(1) 用户请求访问受保护资源的URL, 一般是JSP或者Service, AuthenFilter拦截HTTP访问请求, 并调用相关的认证服务的接口进行认证。如果确认已经认证, 则不需要进行认证动作。否则认证不通过, 则不让访问;

(2) 确认已经认证, 通过传递参数的方式取得对应的客户应用的身份标识, 然后使用所取得的身份标识自动完成应用程序的登录动作, 并设置好相关的登录信息, 放置于Session中, 包括用户ID、角色信息、机构信息等。此后其他JSP或Service操作都按照原有的操作方式处理即可。

通过上述模型方案, 我们对某国有大型企业信息服务平台的各个系统实现了单点登录功能, 提供了基于公司iPlat4J平台的统一解决方案, 方便了用户的使用。例如协同OA平台和e-HR系统的单点登录演示:

(1) 首次访问协同OA系统, 输入网址:http://www.baogang.info/spesDoc/LOGIN/login.jsp, 在登录表单中输入用户名和口令, 登录成功后进入协同OA系统, 如图2所示。

(2) 在左边向导栏内找到员工e-HR自助系统, 点击进入, 浏览器直接显示相关页面内容 (如图3所示) , 而不需要再次登录, 以实现系统间的跳转。

4 结语

单点登录技术作为一种安全技术被越来越广泛地运用到各个领域的软件系统中。我们对SSO模型进行分析和设计, 提出了一种在J2EE平台上通用的单点登录解决方案。对于企业信息服务平台内J2EE架构下的B/S应用, 该解决方案都是适用的, 很好地满足了用户要求, 提高了工作效率, 并且保证了系统的安全性。同时整个解决方案基于规范的Java技术实现, 随着J2EE应用的进一步发展, 企业级客户所面临的应用整合需求越来越多, 关于SSO的方案也将逐步广泛应用, 并且在易操作性、可配置性、安全性方面将得到进一步加强。

摘要：针对某国有大型企业信息服务平台中传统访问控制方式存在的缺陷, 提出了单点登录的概念。在对单点登录模型进行深入分析的基础上, 提出了一种J2EE平台上通用的单点登录的解决方案。该方案不仅可保证认证信息的安全性, 而且便于其各个系统的无缝连接, 能够较好地满足企业信息服务平台上各个系统的单点登录需求。最后以协同OA系统和e-HR系统间跳转情况为例论证了该模型的实现过程。

关键词：单点登录模型,票据,认证服务器,公钥,私钥

参考文献

[1]谢永, 章义来, 李慧颖, 等.信息服务平台的单点登录系统的研究与实现[J].计算机安全, 2008 (8) :74-79.

[2]淡艳, 尹谦.单点登录系统模型分析[J].成都大学学报 (自然科学版) , 2008, 27 (2) :123-126.

[3]赖慎禄, 李新, 及俊川.可插入式单点登录技术的应用[J].计算机工程, 2008, l34 (14) :121-125.

企业信息门户单点登录方案设计 篇5

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) .

一种新的单点登录认证协议 篇6

随着计算机、网络以及信息技术的迅猛发展, 网络的开放性使得人们注册的个人身份资料等信息受到来自网络的各种威胁。因此, 身份信息的管理就成为信息安全领域的研究热点。不少组织和企业开始对身份管理 (Identity Management, IdM) 进行了研究。如ITU-T于2006年提出的全球兼容的身份管理模型;自由联盟 (Liberty Alliance, LA) 提出的身份联合 (Identity Federation) 方案, 还有诸如3GPP、OASIS等国际组织也纷纷提出了自己的身份管理方案或解决办法。但是, 关于身份管理的统一架构和统一模型还未达成统一认识。

单点登录 (Single Sign-on, SSO) 是实现身份管理的一种方式, 其实质是在分布式网络环境下, 为不同应用系统提供统一认证, 并集中管理身份信息的一种技术。在实现SSO的系统中, 用户只需进行一次登录操作, 即可获得所需访问应用系统和资源的认证和授权, 即“一次登录, 多方认证”。目前, 单点登录系统比较成熟的方案有微软公司的Windows Passport和SUN公司领导的Liberty。

Windows Passport属于一种基于访问票据的集中式单点登录模式, 所有用户信息都存放在Passport.com中, 由它负责统一的身份验证。其访问票据以Cookie的形式存放在用户的浏览器里。此种方案的最大缺点是单点失效, 即一旦Passport.com中心站点被黑客攻破, 那将会给整个系统造成巨大损失。另外, Windows Passport是一种付费服务, 而非开放性规范。

相对于Windows Passport, Liberty的SSO并不集中于某个点上, 它是一种基于SAML标准的面向Web服务的开放协议, 其核心思想是身份联合。但Liberty的极端情况与Windows Passport极为类似, 即网络中仅存在一个身份提供者 (Identity Provider, IDP) , 而所有的应用服务器 (Service Provider, SP) 都依赖于同一个IDP进行身份验证。此外, Liberty协议的缺点是管理复杂、缺乏灵活性, 且缺乏相应的授权。

单点登录系统的一个主要环节是其身份认证协议的设计。传统的认证协议一般只涉及两个通信方的相互认证, 且多以客户机/服务器的形式实现。认证协议的形式可能包括:简单的基于用户名/口令的认证方式, 基于挑战/响应的认证方式, 基于公开密钥的认证方式, 以及最著名的Kerberos认证系统等。一个单点登录认证协议应实现用户、认证服务器 (身份提供者) 和应用服务器三方的安全认证机制。即用户与认证服务器、用户与应用服务器、认证服务器与应用服务器在两两通信时都要完成相互认证, 才能最大程度地保证用户的身份信息和传输内容的安全性。我们可以借鉴已有的认证协议来研究SSO的认证协议。即使是三方的相互认证, 每次认证也只能由两方完成。

文献[7]在分析了Kerberos协议局限性的基础上, 给出了一种基于Kerberos协议的改进协议, 该协议安全问题, 考虑了授权机制, 既增强了安全性扩展性。然而, 协议的第二部分 (应用服务鉴别、授权协议) 采用基于共享秘密的认证方式, 一旦攻击者截取了共享密钥, 则可完全解密传输数据。文献[8]给出了一种支持双认证方式的单点登录协议, 该协议也实现了用户与认证服务器的双向认证, 同时基于公钥设计了协议, 消除了对称密钥在实现认证时复杂的密钥管理。但协议在票据验证过程中只是给出了单向的认证协议, 没有实现用户对应用服务器的认证。

本文通过对单点登录系统身份认证协议的分析, 给出一种混合方式的双向认证协议, 综合了密钥协商协议、基于挑战/响应的认证和基于公钥的认证, 实现了各参与方的相互认证, 并结合授权模式, 提高了现有协议的安全性和可扩展性。

1 单点登录认证协议的设计

本文给出了一种新的单点登录的身份认证协议, 结合了基于挑战/响应的认证、基于公钥的认证及密钥协商协议, 实现了用户、认证服务器和应用服务器三方中任意两方的相互认证, 而且能有效抵御常见的攻击手段 (重放攻击、中间人攻击等) 。

1.1 初始化阶段

初始化阶段由认证服务器产生一对公用数值 (g, p) , 其中p是一个素数, g是任一个实数。事实上, 若 (p-1) /2也是一个素数, 将是最理想的。满足这一条件的素数称为安全素数, 或称为Sophie Germain素数。如果满足除了x=0 mod p-1以外, 对于其它x都有gx≠1 mod p, 则更为理想。

1.2 注册阶段

协议的注册过程如下:

(1) 用户端注册。每个用户需要在认证服务器中注册, 完成注册后, 认证服务器发给用户一个公钥证书作为用户的身份标识IDu, 包括用户名、用户的公钥、版本号、序列号、证书有效时间及认证服务器对整个信息的签名。

(2) 应用服务注册。每个应用服务需要在认证服务器中注册相应的应用标识IDaps。此标识实际上是一个公钥证书, 包括应用服务名、公钥、版本号、序列号、证书有效时间及认证服务对此信息的签名。

1.3 协议流程

协议中用到的标识说明详见表1。

第一部分:登录认证协议

在协议中, Ru表示U产生的挑战因子, Ras表示AS产生的挑战因子, K表示协商的会话密钥, 实际上K=gabmod p。

协议执行过程如下: (1) 用户选择随机数a, 并计算K=ga mod p, 然后连同自己的身份标识IDu一起用AS的公钥加密后, 发送给认证服务器; (2) AS用Kas-1解密出gamod p, 并计算gabmod p, 将结果暂时保存。然后选择随机数b, 计算gb mod p, 连同挑战因子Ras一起用U的公钥加密, 而后发送给用户; (3) U用Ku-1解密M2, 并计算K=gabmod p, 然后选择挑战Ru, 并用K加密{Ras, Ru}, 发送给认证服务器; (4) AS接收M3后用K解密, 如果看到Ras, 则确认对方是U, 同时将Ru用K加密并返回给U;否则, 拒绝对方的登录认证请求。

U接收到M4后, 用K解密, 如果看到Ru, 则确认对方是认证服务器;否则拒绝协议的继续执行。

第二部分:票据验证协议

用户登录成功后, 认证服务器为用户产生一个临时认证票据, 格式为:

tiket=user_name ST ET ipaddr[hashvalue]k

其中user_name表示用户名, ST表示票据有效起始时间, 也即登录时间, ET表示票据有效终止时间。ipaddr表示登录的地址。[hashvalue]Kas表示用AS的公钥对票据信息散列值的签名。

用户访问应用服务时, 票据验证协议为:

在协议中, RS1和RS2都是随机挑战, flag表示授权信息位, 即表示认证服务对用户的票据验证后, 返回给应用服务的结果。

协议的执行过程如下: (5) 当U访问APS时, APS向U发送数据包M5。即用U的公钥加密应用服务标识IDaps和一个随机挑战RS1, 然后将结果发给U; (6) U收到M5后, 先用私钥解密得到随机挑战RS1, 然后用应用服务的公钥加密用户服务标识、RS1和随机挑战RS2, 以及用认证协议得到的会话密钥K加密票据, 形成数据包M6, 并发送给应用服务; (7) 应用服务收到M6后, 解密得到RS1和RS2, 在此, 应用服务收到RS1就能确认用户的身份。之后, 应用服务使用认证服务的公钥Kas加密应用服务标识IDaps和RS1、RS2, 联合Ek[ticket]形成数据包M7, 并发送给认证服务; (8) 认证服务收到M7后, 用会话密钥解密票据, 并对其进行验证。验证通过, 则用私钥Kas-1解密得到随机挑战RS1和RS2, 之后再用应用服务的公钥加密授权信息flag和随机挑战RS1, 用会话密钥加密随机挑战RS2, 形成数据包M8, 发送给应用服务;若验证失败, 则返回失败信息; (9) 应用服务收到M8后, 解密得到授权信息, 根据授权信息决定是否向用户提供服务。同时将会话密钥K加密的随机挑战RS2返回给用户。

用户收到M9后, 解密得到RS2, 由此可以确认此过程确实有认证服务参加 (只有认证服务知道会话密钥) , 同时验证了应用服务的身份。

2 安全性分析

首先, 协议是双向认证协议, 不论是登录认证还是授权认证都完成了通信双方身份的相互认证, 比起传统的单向认证, 其安全性有所增强。

协议的第一部分采用基于公钥的双向认证, 并结合DiffieHellman密钥协商协议修改而来。该协议保证了攻击者同时入侵用户和认证服务器, 也不能解密所得到的通信内容, 无法计算出a或b (这是由离散对数问题的复杂度保证的) , 从而无法得到其会话密钥K。

此外, 在协议执行过程的步骤 (1) 中用户使用认证服务的公钥Kas加密[gamod p, IDu], 这就使得协议可以抵抗中间人攻击。即使攻击者向服务器冒充自己为用户且完成了步骤 (1) 和 (2) , 但在步骤 (3) 中攻击者却无法解密M2, 因为M2使用真实用户的公钥加密, 攻击者不知道用户的私钥, 也就无法解密, 从而无法完成协议。避免了中间人攻击。

其次, 协议中使用随机数, 是一种挑战/响应的认证模式, 该模式比使用时间戳的认证协议更方便, 它不需要时间同步来维护时间一致性, 且每次认证的不同随机数保证攻击者不能实施重放攻击。

在协议的第二部分执行过程的步骤 (5) 、 (6) 中的这两个随机挑战都是为了防止对各自的数据包进行重放攻击。在步骤 (7) 中, 当应用服务解密得到随机数RS1时, 就能确认用户的合法身份。而在步骤 (9) 中, 应用服务将会话密钥K加密的随机挑战RS2返回给用户, 使得用户相信该过程确实有认证服务参与, 且应用服务是真实的。通过步骤 (4) 到步骤 (9) 的过程也使应用服务确信用户是真实的, 只有通过认证服务验证用户的票据正确后, 才会发送步骤 (8) 中数据包给应用服务, 否则将发送失败信息。

综上, 协议过程实现了用户、认证服务和应用服务三方的双向认证, 理论上增强了协议的安全性。该协议中票据的校验工作由认证服务完成, 应用服务起到过渡作用, 同时在过渡中应用服务不但获得用户端的认证, 获得对认证服务的认证, 并取得相应的授权信息, 在访问控制及授权需要细化时更易于扩展。

3 结束语

本文对现有的单点登录协议进行了研究和改进, 提出一种基于挑战/响应认证、公钥认证和密钥协商协议的认证协议, 增强了身份认证协议的安全性和扩展性。同时, 由于实现双向认证均采用基于公钥的认证协议, 协议的实现效率会受影响。需要在实际中对安全性和效率做出权衡。当然, 该协议仅完成了域内的单点登录认证协议, 至于跨域的认证协议还需进一步研究。

参考文献

[1]Focus Group, SG-17, ITU-T.Report on Identity Management Frame-work for Global Interoperability.2007.

[2]Focus Group, SG-17, ITU-T.Report on Requirements for Global In-teroperable Identity Management.2007.

[3]Focus Group, SG-17, ITU-T.Report on Identity Management Use Cases and Gap Analysis.2007.

[4]3GPP.3GPP TS32.140, Subscription Management (SuM) require-ments.2007.

[5]3GPP.3GPP TS32.141, Subscription Management (SuM) architec-ture.2007.

[6]OASIS, Security Assertion Markup Language (SAML v2.0) , http://www.oasis-open.org/specs/index.php#samlv2.0.2005.

[7]李继勇, 陶然.一种单点登录协议的设计[J].计算机工程, 2008 (14) .

[8]杨智, 陈性元, 张斌.支持双认证的单点登录方案[J].计算机应用, 2007 (3) .

[9]MICROSOFT PASSPORT REVIEW GUIDE.http://www.microsoft.com/net/serv-ices/passport/review guide.asp, March13, 2003.

[10]LIBERTY ALLIANCE PROJECT.Liberty Architecture Overview.2003.

[11]CHARLIE KAUFMAN, RADIA PERLMAN.网络安全—公众世界中的秘密通信 (第二版) [M].许剑卓, 左英男, 译.北京:电子工业出版社, 2004.

单点登录模型 篇7

随着信息化建设的推进, 提供给用户使用的业务信息系统越来越多。每个业务系统都有各自独立的登录认证功能及用户信息管理功能, 缺乏统一的信息系统登录入口和用户帐号管理机制, 用户需记忆的不同系统的登录帐号和密码越来越多, 造成用户使用不便。对用户帐号信息进行统一规划和管理, 对用户身份进行统一认证使用户进行单点登录访问, 是当前信息化建设的方向。Novell Access Manager是Novell公司提供的统一身份认证解决方案, 它为上述问题提供了圆满解决方案。

2 实现统一身份认证和单点登录的必要性

信息系统传统的用户身份管理和登录方式存在弊端, 表现为:

(1) 每套业务系统都开发有自己的用户帐号管理功能, 用户帐号在每套系统中都需要单独创建, 同一个人在多套业务系统中可能存在多个用户帐号, 在登录不同的业务系统时需要使用不同的帐号密码, 用户需要记忆多个帐号和密码, 使用不便, 用户体验下降。

(2) 每套系统都有自己的用户登录页面和认证机制, 用户界面各异, 认证安全性水平有高有低, 不能提供给用户统一的视觉界面和系统安全性。特别是用户登录进入门户后访问业务系统时, 仍然显示登录页面要求再次输入帐号密码, 用户体验不佳。

因此, 为消除以上弊端, 应进行以下改进:

(1) 进行统一用户建设。随着业务系统横向集成的推进, 需要将用户信息单独抽取出来作为信息系统的基础设施进行统一建设和规范化管理, 然后将用户信息从权威数据源分发至各业务系统, 各业务系统不再保留独立的用户管理功能。

(2) 实现统一认证和单点登录访问。给用户提供统一的访问入口进行单点登录访问。单点登录的含义是用户只需一次登录就可以访问不同的业务系统。用户无需再记忆多个帐号, 只需记住统一用户系统中自己的一个帐号即可, 用一个帐号访问所有业务系统, 而且在登录门户后访问业务系统时也无需再重复输入帐号和密码, 提高了信息系统的易用性、安全性, 改善了用户体验。

Novell Access Manager ( 以下简称Novell AM) 是Novell公司提供的统一认证解决方案, 业务系统与Novell Access Manager进行集成就可实现业务系统的单点登录。

3 Novell AM系统架构

Novell AM系统由身份认证管理服务器 (Identity Server, 简称IDS) 、 访问网关 (Access Gateway, 简称AG) 、 目录服务器 (LDAP Directory) 、管理控制台 (Administration Console, 简称AC) 组成, 提供对用户身份的统一认证和对业务应用系统的安全访问。系统架构如图1。

系统各组件的功能如下:

(1) IDS:身份认证管理服务器, 负责对用户身份信息进行认证, 向用户推送统一的身份认证页面, 将用户在认证页面中输入的用户名、密码提交至用户身份信息库LDAP Directory进行认证, 判断是否为合法用户。IDS支持用户名/ 密码、X.509 数字证书、令牌等多种认证方式。IDS可由多台服务器组成集群。

(2) AG:访问网关, 基于反向代理服务, 利用自动填表或身份注入等技术实现对业务系统的单点登录访问。业务系统与AG集成后对业务系统的所有访问都受到AG保护, 此时提供给用户的访问地址不再是业务系统原来自己Web服务器的地址, 而是DNS域名形式的AG服务器的地址, 业务系统位于AG之后, 用户访问业务系统首先需要经过AG, 从而AG为业务系统提供安全访问控制, 提高了业务系统的安全性。AG可由多台服务器组成集群。

(3) LDAP Directory:用户身份信息数据库, 存储着权威的用户帐号名称、密码等身份信息, IDS使用它作为唯一的用户身份认证数据源。

(4) AC:管理控制台, 实现对IDS、AG、业务系统单点登录的配置功能, 同时提供IDS、AG间的通信服务功能。AC可由两台服务器组成主备关系的HA架构。

4 Novell AM单点登录实现

4.1 单点登录流程

业务系统通过Novell AM进行访问的流程如图2。

图2 的登录流程 ( 对应图中所标序号) 分析如下:

(1) 用户向受AG保护的业务系统 (Web Server) 发出访问请求, 因为业务系统已受AG保护, 所以用户访问请求首先被发送到AG。

(2) AG检查当前用户是否已登录, 如果用户尚未登录, 利用HTTP协议重定向机制, 用户访问请求被AG重定向到身份认证管理服务器Identity Server, IDS向用户推送身份认证页面, 即登录页面, 提示用户输入用户名和密码, 用户输入用户名、密码后提交。

(3) IDS获取到用户提交的用户名、密码信息, 然后IDS到用户身份信息数据库LDAP Directory中对获取到的用户身份信息进行认证, 验证用户合法性。若IDS验证不通过, 则用户浏览器仍然停留在登录页面, 提示用户重新数据用户名、密码。

(4) 在上步骤中, 若IDS认证通过, 则IDS返回认证成功的信息到用户浏览器, 用户浏览器重新将访问业务系统的请求发送至AG。

(5) AG向IDS确认用户已经被IDS认证成功, 是合法用户, 并且AG向IDS请求获得已认证通过的用户的身份信息, AG得到IDS发送的用户身份信息。

(6) AG在获得用户身份信息后, AG利用自动填表或者身份注入等方法向受保护业务系统Web Server发送用户身份信息。

(7) 业务系统认为当前访问用户是合法用户, 接受用户访问请求, 将用户请求信息发送给用户浏览器。完成登录流程。

4.2 统一用户

统一用户的建设首先需要确定一个身份权威源, 权威源是指对确定用户身份关键信息进行管理维护的应用系统, 一般推荐将人力资源系统作为身份权威源, 也可以定制开发身份权威源系统。建立权威源的目的是从源头对用户身份信息进行控制和规范化管理, 作为用户身份信息的唯一出处, 改变以往用户身份信息各业务系统重复建设、管理分散的局面。

Novell公司的Identity Manager组件能够实现将身份信息从权威源到LDAP Directory再到相关业务应用系统的实时同步, 包括用户账号的同步创建、变更、删除等, 实现全生命周期管理。在权威源中可以制定账号管理策略对用户身份信息到业务系统的同步进行控制, 控制哪些帐号可以同步到哪些业务系统, 达到需要的帐号才能同步到需要的业务系统的目的。用户身份信息同步的数据流如图3。

统一用户建立后, 用户身份信息就成为了一个在所有业务系统间共享、流动、一致的基础数据, 为不同业务系统间的单点登录奠定了数据基础。

4.3 基于自动填表策略的集成方式

对于大多数B/S业务系统, 使用表单页面作为系统的登录页面, 因此AG向业务应用系统发送用户身份信息, 大多使用自动填表策略来完成。在图2 登录流程所示的第6 步中, AG在获得用户身份信息后, 自动向业务系统的登录页面填入用户帐号、密码信息, 并对业务系统的登录页面进行自动提交, 从而登录进入业务系统。

基于自动填表策略的集成方式适用于从企业门户到其它业务应用系统入口的业务导航跳转, 用户无需再次输入用户名密码, 实现单点登录。

4.4 基于身份注入 (即HTTP头) 策略的集成方式

在用户通过IDS认证后, AG通过注入机制在HTTP请求中添加表示用户信息的HTTP头, 并将请求转发到业务应用系统, 业务系统获取HTTP头中的用户身份信息, 完成对用户身份信息的接收和认证。业务应用系统需要按照AG接口规范的要求, 利用HTTP协议中规定的基本认证方式登录应用系统, 也可以使用认证系统与应用系统之间约定的头信息登录。

此方式适合于从企业门户到其它应用系统业务功能页面的跳转, 如进入待办任务对应的业务应用系统的处理页面。

4.5 典型应用

当前, 企业往往以门户为中心实现各业务系统的应用集成和数据集成, 因此, 企业信息化的典型应用场景是将企业门户系统及各业务应用系统与Novell AM集成, 然后将门户作为企业信息系统的唯一访问入口对用户开放, 用户登录进入门户后对各业务系统进行单点登录式访问, 如图4所示。

5 结束语

统一认证和单点登录的实现, 标志着信息系统横向集成的建设推进到了一个新阶段, 为用户带来崭新体验, 大大方便用户使用信息系统。本文描述了基于Novell AM的实现方案, 为企业建设统一认证提供了切实可行的一种选择。

摘要：随着信息化建设横向集成的推进, 对用户身份信息进行统一认证和为用户提供单点登录访问方式的必要性日益提高, 如何实现统一认证和单点登录是信息化建设的重要课题。Novell AM是Novell公司提供的统一身份认证解决方案, 它通过反向代理、自动填表等技术实现信息系统的单点登录, 为企业建设统一认证提供了切实可行的一种方案。

关键词：单点登录,身份认证,访问网关,统一认证

参考文献

[1]霍成义.结合Cookie与票据共享的单点登录方案[J].自动化与仪器仪表, 2013, 3:167-169.