单点登陆系统SSO原理

     SSO（Single Sign-On，单点登录）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。
SSO与身份管理软件背景

   目前的企业应用环境中，往往有很多的应用系统，如办公自动化（ OA ）系统，财务管理系统，档案管理系统，信息查询系统等等。这些应用系统服务于企业的信息化建设，为企业带来了很好的效益。但是，用户在使用这些应用系统时，并不方便。用户每次使用系统，都必须输入用户名称和用户密码，进行身份验证；而且，应用系统不同，用户账号就不同，用户必须同时牢记多套用户名称和用户密码。特别是对于应用系统数目较多，用户数目也很多的企业，这个问题尤为突出。问题的原因并不是系统开发出现失误，而是缺少整体规划，缺乏统一的用户登录平台。
   使用SSO技术可以解决以上这些问题，SSO是身份管理中的一部分，关于安全与身份管理软件市场，可参考： http://www.blogjava.net/ablix/archive/2005/12/28/25804.html

使用 SSO 的好处

   使用 SSO 的好处主要有：

      (1) 方便用户

   用户使用应用系统时，能够一次登录，多次使用。用户不再需要每次输入用户名称和用户密码，也不需要牢记多套用户名称和用户密码。单点登录平台能够改善用户使用应用系统的体验。

      (2) 方便管理员

   系统管理员只需要维护一套统一的用户账号，方便、简单。相比之下，系统管理员以前需要管理很多套的用户账号。每一个应用系统就有一套用户账号，不仅给管理上带来不方便，而且，也容易出现管理漏洞。

      (3) 简化应用系统开发

   开发新的应用系统时，可以直接使用单点登录平台的用户认证服务，简化开发流程。单点登录平台通过提供统一的认证平台，实现单点登录。因此，应用系统并不需要开发用户认证程序。

二、
实现SSO的技术主要有：

      (1)基于cookies实现，需要注意如下几点：如果是基于两个域名之间传递sessionid的方法可能在windows中成立，在unix&linux中可能会出现问题；可以基于数据库实现；在安全性方面可能会作更多的考虑。另外，关于跨域问题，虽然cookies本身不跨域，但可以利用它实现跨域的SSO。

      (2)Broker-based(基于经纪人)，例如Kerberos等；

   这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的"第三方"。例如Kerberos、Sesame、IBM KryptoKnight（凭证库思想）等。

      (3)Agent-based(基于代理人)

   在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如, 它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个"翻译"。例如SSH等。

      (4)Token-based，例如SecurID、WebID、

   现在被广泛使用的口令认证，比如FTP，邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。

      (5)基于网关

      Agent and Broker-based，这里不作介绍。

      (6)基于安全断言标记语言(SAML)实现，SAML（Security Assertion Markup Language，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。开源组织OpenSAML 实现了 SAML 规范，可参考 http://www.opensaml.org 。

三、

SUN  SSO技术
      SUN SSO技术是Sun Java System Access Manager产品中的一个组成部分。
      Sun 的新身份管理产品包括Sun Java System Identity Manager、Sun Java System Directory Server Enterprise Edition 和 Sun Java System Access Manager，以上三者为Sun Java Identity Management Suite (身份识别管理套件)的组成部分，它们与Sun Java Application Platform Suite、Sun Java Availability Suite、Sun Java Communications Suite、Sun Java Web Infrastructure Suite组成Java ES。具有革新意义的这一系列产品提供端到端身份管理，同时可与 60 多种第三方资源和技术实现互操作，集成产品可以从SUN公司网站下载，一般以Agent软件方式提供，是业内集成程序最高、最为开放的身份管理解决方案之一。
   在Sun 的新身份管理产品中， Sun Java System Access Manager是基中的一个重要组成部分，Java Access Manager基于J2EE架构，采用标准的API，可扩展性强，具有高可靠性和高可用性，应用是部署在Servlets容器中的，支持分布式，容易部署且有较低的TCO。通过使用集中验证点、其于角色的访问控制以及 SSO，Sun Java System Access Manager 为所有基于 Web 的应用程序提供了一个可伸缩的安全模型。它简化了信息交换和交易，同时能保护隐私及重要身份信息的安全。

四、

CAS 背景介绍

      CAS（Central Authentication Service），是耶鲁大学开发的单点登录系统（SSO，single sign-on），应用广泛，具有独立于平台的，易于理解，支持代理功能。CAS系统在各个大学如耶鲁大学、加州大学、剑桥大学、香港科技大学等得到应用。

      Spring Framework的Acegi安全系统支持CAS，并提供了易于使用的方案。Acegi安全系统，是一个用于Spring Framework的安全框架，能够和目前流行的Web容器无缝集成。它使用了Spring的方式提供了安全和认证安全服务，包括使用Bean Context，拦截器和面向接口的编程方式。因此，Acegi安全系统能够轻松地适用于复杂的安全需求。Acegi安全系统在国内外得到了广泛的应用，有着良好的社区环境。

CAS 的设计目标

      (1)为多个Web应用提供单点登录基础设施，同时可以为非Web应用但拥有Web前端的功能服务提供单点登录的功能；

      (2)简化应用认证用户身份的流程；

      (3)将用户身份认证集中于单一的Web应用，让用户简化他们的密码管理，从而提高安全性；而且，当应用需要修改身份验证的业务逻辑时，不需要到处修改代码。

CAS 的实现原理

      CAS（Central Authentication Server）被设计成一个独立的Web应用。实现原理非常简单，CAS Server

CAS 在应用中的运行硬件环境
      University of

      CAS创建一个位数很长的随机数（ticket）。CAS把这个ticket和成功登录的用户以及用户要访问的service联系起来。例如，如果用户peon重定向自service S，CAS创建ticket T，这个ticket T允许peon访问service S。这个ticket是个一次性的凭证；它仅仅用于peon和仅仅用于service S，并且只能使用一次，使用之后马上会过期，即ticket通过验证，CAS立即删除该ticket，使它以后不能再使用。这样可以保证其安全性。

   关于ST，在取一个ST时，即使用deleteTicket(ticketId)同时将一次性的ST删除；而对于TGT或PT，则通过resetTimer(ticketId)以更新TGT或PT的时间。在CAS服务端返回的ST中只能得出用户名。
      另外，CAS3.0版本也已经发布了，现在最新的版本是3.03，希望CAS3.0在向下兼容的同时，更能向我们提供一些新东西。 
 

 

SUN SSO 实现原理

      SSO的核心在于统一用户认证，登录、认证请求通过 IDENTITY SERVER服务器 完成，然后分发到相应应用。

      SUN SSO是java Access Manager的一个组成部分， SSO 基于 Cookie 实现解释如下：

      (1)Policy Agent on Web or Application Server intercepts resource requests and enforces access control;

      (2)Client is issued SSO token containing information for session Validation with Session service.

      (3)SSO token has no content- just a long random string used as a handle.

      (4)Web-based applications use browser session cookies or URL rewriting to issue SSO token.

      (5)Non Web applications use the SSO API(Java/c) to obtain the SSO token to validate the users identity.

SUN SSO 的应用

   这里说的应用是指 Sun Java System Access Manager 的应用。成功应用例子很多，包括德国电信等公司的应用，国内也有大量高校在使用，也有相当多的其它行业的应用。

SUN SSO的开源
      Sun 将发布其网络验证与网络单点登录技术，给一项新的开放源代码计划“Open Web Single Sign-On”（Open SSO）。 OpenSSO 网站位于： https://opensso.dev.java.net/ 。该网站对 OpenSSO的概述为： This project is based on the code base of Sun Java(tm) System Access Manager Product, a core identity infrastructure product offered by Sun Microsystems.

      OpenSSO 计划的第一部份源代码，将于今年年底完成，基本的版本将于明年3月份发布，而完整的版本可能要等到明年五月份。 Sun 采用 与 Solaris 操作系统相同的共同开发暨流通授权（ Common Development and Distribution License ）方式。

本文以某新闻单位多媒体数据库系统为例，提出建立企业用户认证中心，实现基于安全策略的统一用户管理、认证和单点登录，解决用户在同时使用多个应用系统时所遇到的重复登录问题。

随着信息技术和网络技术的迅猛发展，企业内部的应用系统越来越多。比如在媒体行业，常见的应用系统就有采编系统、排版系统、印刷系统、广告管理系统、财务系统、办公自动化系统、决策支持系统、客户关系管理系统和网站发布系统等。由于这些系统互相独立，用户在使用每个应用系统之前都必须按照相应的系统身份进行登录，为此用户必须记住每一个系统的用户名和密码，这给用户带来了不少麻烦。特别是随着系统的增多，出错的可能性就会增加，受到非法截获和破坏的可能性也会增大，安全性就会相应降低。针对于这种情况，统一用户认证、单点登录等概念应运而生，同时不断地被应用到企业应用系统中。

统一用户管理的基本原理

一般来说，每个应用系统都拥有独立的用户信息管理功能，用户信息的格式、命名与存储方式也多种多样。当用户需要使用多个应用系统时就会带来用户信息同步问题。用户信息同步会增加系统的复杂性，增加管理的成本。

例如，用户X需要同时使用A系统与B系统，就必须在A系统与B系统中都创建用户X，这样在A、B任一系统中用户X的信息更改后就必须同步至另一系统。如果用户X需要同时使用10个应用系统，用户信息在任何一个系统中做出更改后就必须同步至其他9个系统。用户同步时如果系统出现意外，还要保证数据的完整性，因而同步用户的程序可能会非常复杂。

解决用户同步问题的根本办法是建立统一用户管理系统（UUMS）。UUMS统一存储所有应用系统的用户信息，应用系统对用户的相关操作全部通过UUMS完成，而授权等操作则由各应用系统完成，即统一存储、分布授权。UUMS应具备以下基本功能:

1．用户信息规范命名、统一存储，用户ID全局惟一。用户ID犹如身份证，区分和标识了不同的个体。

2．UUMS向各应用系统提供用户属性列表，如姓名、电话、地址、邮件等属性，各应用系统可以选择本系统所需要的部分或全部属性。

3．应用系统对用户基本信息的增加、修改、删除和查询等请求由UUMS处理。

4．应用系统保留用户管理功能，如用户分组、用户授权等功能。

5．UUMS应具有完善的日志功能，详细记录各应用系统对UUMS的操作。

统一用户认证是以UUMS为基础，对所有应用系统提供统一的认证方式和认证策略，以识别用户身份的合法性。统一用户认证应支持以下几种认证方式:

1. 匿名认证方式: 用户不需要任何认证，可以匿名的方式登录系统。

2. 用户名/密码认证: 这是最基本的认证方式。

3. PKI/CA数字证书认证: 通过数字证书的方式认证用户的身份。

4. IP地址认证: 用户只能从指定的IP地址或者IP地址段访问系统。

5. 时间段认证: 用户只能在某个指定的时间段访问系统。

6. 访问次数认证: 累计用户的访问次数，使用户的访问次数在一定的数值范围之内。

以上认证方式应采用模块化设计，管理员可灵活地进行装载和卸载，同时还可按照用户的要求方便地扩展新的认证模块。

认证策略是指认证方式通过与、或、非等逻辑关系组合后的认证方式。管理员可以根据认证策略对认证方式进行增、删或组合，以满足各种认证的要求。比如，某集团用户多人共用一个账户，用户通过用户名密码访问系统，访问必须限制在某个IP地址段上。该认证策略可表示为: 用户名/密码“与”IP地址认证。

PKI/CA数字证书认证虽不常用，但却很有用，通常应用在安全级别要求较高的环境中。PKI（Public Key Infrastructure）即公钥基础设施是利用公钥理论和数字证书来确保系统信息安全的一种体系。

在公钥体制中，密钥成对生成，每对密钥由一个公钥和一个私钥组成，公钥公布于众，私钥为所用者私有。发送者利用接收者的公钥发送信息，称为数字加密，接收者利用自己的私钥解密; 发送者利用自己的私钥发送信息，称为数字签名，接收者利用发送者的公钥解密。PKI通过使用数字加密和数字签名技术，保证了数据在传输过程中的机密性（不被非法授权者偷看）、完整性（不能被非法篡改）和有效性（数据不能被签发者否认）。

数字证书有时被称为数字身份证，数字证书是一段包含用户身份信息、用户公钥信息以及身份验证机构数字签名的数据。身份验证机构的数字签名可以确保证书信息的真实性。

完整的PKI系统应具有权威认证机构CA（Certificate Authority）、证书注册系统RA（Registration Authority）、密钥管理中心KMC（Key Manage Center）、证书发布查询系统和备份恢复系统。CA是PKI的核心，负责所有数字证书的签发和注销; RA接受用户的证书申请或证书注销、恢复等申请，并对其进行审核; KMC负责加密密钥的产生、存贮、管理、备份以及恢复; 证书发布查询系统通常采用OCSP（Online Certificate Status Protocol，在线证书状态协议）协议提供查询用户证书的服务，用来验证用户签名的合法性; 备份恢复系统负责数字证书、密钥和系统数据的备份与恢复。

单点登录

单点登录（SSO，Single Sign-on）是一种方便用户访问多个系统的技术，用户只需在登录时进行一次注册，就可以在多个系统间自由穿梭，不必重复输入用户名和密码来确定身份。单点登录的实质就是安全上下文（Security Context）或凭证（Credential）在多个应用系统之间的传递或共享。当用户登录系统时，客户端软件根据用户的凭证（例如用户名和密码）为用户建立一个安全上下文，安全上下文包含用于验证用户的安全信息，系统用这个安全上下文和安全策略来判断用户是否具有访问系统资源的权限。遗憾的是J2EE规范并没有规定安全上下文的格式，因此不能在不同厂商的J2EE产品之间传递安全上下文。

图1 SSO原理示意图

目前业界已有很多产品支持SSO，如IBM的WebSphere和BEA的WebLogic，但各家SSO产品的实现方式也不尽相同。WebSphere通过Cookie记录认证信息，WebLogic则是通过Session共享认证信息。Cookie是一种客户端机制，它存储的内容主要包括: 名字、值、过期时间、路径和域，路径与域合在一起就构成了Cookie的作用范围，因此用Cookie方式可实现SSO，但域名必须相同; Session是一种服务器端机制，当客户端访问服务器时，服务器为客户端创建一个惟一的SessionID，以使在整个交互过程中始终保持状态，而交互的信息则可由应用自行指定，因此用Session方式实现SSO，不能在多个浏览器之间实现单点登录，但却可以跨域。

实现SSO有无标准可寻？如何使业界产品之间、产品内部之间信息交互更标准、更安全呢？基于此目的，OASIS（结构化信息标准促进组织）提出了SAML解决方案（有关SAML的知识参看链接）。

用户认证中心实际上就是将以上所有功能、所有概念形成一个整体，为企业提供一套完整的用户认证和单点登录解决方案。一个完整的用户认证中心应具备以下功能:

1. 统一用户管理。实现用户信息的集中管理，并提供标准接口。

2. 统一认证。用户认证是集中统一的，支持PKI、用户名/密码、B/S和C/S等多种身份认证方式。

图2 统一用户认证与单点登录设计模型

3. 单点登录。支持不同域内多个应用系统间的单点登录。

用户认证中心提供了统一认证的功能，那么用户认证中心如何提供统一授权的功能呢？这就是授权管理中，其中应用最多的就是PMI。

PMI（Privilege Management Infrastructure，授权管理基础设施）的目标是向用户和应用程序提供授权管理服务，提供用户身份到应用授权的映射功能，提供与实际应用处理模式相对应的、与具体应用系统开发和管理无关的授权和访问控制机制，简化具体应用系统的开发与维护。PMI是属性证书（Attribute Certificate）、属性权威（Attribute Authority）、属性证书库等部件的集合体，用来实现权限和证书的产生、管理、存储、分发和撤销等功能。

PMI以资源管理为核心，对资源的访问控制权统一交由授权机构统一处理，即由资源的所有者来进行访问控制。同公钥基础设施PKI相比，两者主要区别在于: PKI证明用户是谁，而PMI证明这个用户有什么权限，能干什么，而且PMI可以利用PKI为其提供身份认证。

单点登录通用设计模型

图2是统一用户认证和单点登录通用设计模型，它由以下产品组成:

1. PKI体系: 包括CA服务器、RA服务器、KMC和OCSP服务器。

2. AA管理服务器: 即认证（Authentication）和授权（Authorization）服务器，它为系统管理员提供用户信息、认证和授权的管理。

3. UUMS模块: 为各应用系统提供UUMS接口。

4. SSO: 包括SSO代理和SSO服务器。SSO代理部署在各应用系统的服务器端，负责截获客户端的SSO请求，并转发给SSO服务器，如果转发的是OCSP请求，则SSO服务器将其转发给OCSP服务器。在C/S方式中，SSO代理通常部署在客户端。

5. PMI: 包括PMI代理和PMI服务器。PMI代理部署在各应用系统的服务器端，负责截获客户端的PMI请求，并转发给PMI服务器。

6. LDAP服务器: 统一存储用户信息、证书和授权信息。

为判断用户是否已经登录系统，SSO服务器需要存储一张用户会话（Session）表，以记录用户登录和登出的时间，SSO服务器通过检索会话表就能够知道用户的登录情况，该表通常存储在数据库中。AA系统提供了对会话的记录、监控和撤消等管理功能。为保证稳定与高效，SSO、PMI和OCSP可部署两套或多套应用，同时提供服务。

链接

SAML

SAML（Security Assertion Markup Language，安全性断言标记语言）是一种基于XML的框架，主要用于在各安全系统之间交换认证、授权和属性信息，它的主要目标之一就是SSO。在SAML框架下，无论用户使用哪种信任机制，只要满足SAML的接口、信息交互定义和流程规范，相互之间都可以无缝集成。SAML规范的完整框架及有关信息交互格式与协议使得现有的各种身份鉴别机制（PKI、Kerberos和口令）、各种授权机制（基于属性证书的PMI、ACL、Kerberos的访问控制）通过使用统一接口实现跨信任域的互操作，便于分布式应用系统的信任和授权的统一管理。

SAML并不是一项新技术。确切地说，它是一种语言，是一种XML描述，目的是允许不同安全系统产生的信息进行交换。SAML规范由以下部分组成:

1. 断言与协议: 定义XML格式的断言的语法语义以及请求和响应协议。SMAL主要有三种断言: 身份认证断言、属性断言和访问授权断言。

2. 绑定与配置文件: 从SAML请求和响应消息到底层通信协议如SOAP或SMTP的映射。

3. 一致性规范: 一致性规范设置了一种基本标准，必须满足这一SAML标准的实现才能够称为一致性实现。这样有助于提高互操作性和兼容性。

4. 安全和保密的问题: SAML体系结构中的安全风险，具体而言就是SAML如何应对这些风险以及无法解决的风险。

要注意的是，SAML并不是专为SSO设计，但它却为SSO的标准化提供了可行的框架。  

单点登陆系统SSO原理