浅谈Shibboleth和SAML的系统如何跨校统一身份

　　随着技术的发展，越来越多的大学、公司以及政府机构都通过网络对外提供资源、服务，并且彼此协作日益紧密、信息共享日益频繁。例如，大学之间的“跨校选课”、“共享图书资源”等。因此简化这些业务中身份的流程，同时做到安全高效成为迫切需要解决的问题。

　　1 Shibboleth简介

　　Shibboleth是一个针对SSO的开源项目。Shibboleth项目主要应用在校园内Web资源共享，以及校园间的应用系统的用户身份联合。

　　Shibboleth主要针对分布式资源如何有效访问的问题。与其他系统的区别在于Shibboleth将模块放在客户端，资源提供者只需进行少量的验证工作，极大地减轻了资源提供者的负担，简化了访问程序、提高了访问资源的效率、安全性得到了保证。在系统扩展方面，Shibboleth采用了SAML规范，同时也在SAML上作了改进，保证了系统的可扩展性。

　　Shibboleth主要由3个部分组成：

　　(1)Origin

　　对应Identity Provider(IdP)，身份提供端。主要作用是向资源提供者提供用户的属性，以便使资源服务器根据其属性对操作进行判决响应。

　　(2)Target

　　对应Resource/Service Provider，资源/服务提供端。主要作用是响应用户的资源请求，并向该用户所在的Origin查询用户的属性，然后根据属性做出允许或拒绝访问资源的决策。

　　(3)WAYF

　　WAYF是Where Are You From的首字母简称。SHIRE使用WAYF来进行大部分初始化工作。WAYF组件知道每一个Origin端句柄服务器的名称和位置。其主要功能是将Origin端站点名称映射到HS信息上。WAYF的另一个作用是为用户查询HS并将句柄发送给SHIRE。WAYF通过与用户打交道，询问“你从哪来”，用户输入组织名称，WAYF便在用户组织的名称与HS的URL之间进行映射。

　　2 SAML简介

　　SAML即安全断言标记语言，英文全称是Security Assertion Markup Language。它是一个基于XML的标准，用于在不同的安全域(security domain)之间交换和授权数据。在SAML标准定义了身份提供者(identity provider)和服务提供者(service provider)，这两者构成了前面所说的不同的安全域。 SAML是OASIS组织安全服务技术委员会(Security Services Technical Committee)的产品。SAML将所有与检索、传输和共享安全信息相关的功能标准转化为以下形式[2]：

　　(1)为用户提供XML安全信息格式，请求、传输信息的格式。

　　(2)定义这些消息与SOAP(Simple Object Access Protocol)等协议协作的方式。

　　(3)为像Web SSO(Single Sign-On)类似的常见用例定义的消息交换。

　　(4)支持多种隐私保护机制，包括在不披露用户身份的情况下确定用户属性的功能。

　　(5)详述在Unix、Microsoft Windows、X509、LDAP、DCE和XCML技术所提供的格式中处理身份信息的方法。

　　(6)提供系统的元数据机制，使得所有参与的系统能就所支持的SAML选项进行通信。

    SAML的设计特别关注了灵活性，当遇到标准尚未涵盖的需求时，可以扩展。其所描述的环境包括3个角色，如图1所示，即信任方(Service Provider)、断言方(Identity Provider)和主题(与身份信息相关的用户)。

　　SAML（Security Assertion Markup Language）是一个XML框架，也就是一组协议，可以用来传输安全声明。比如，两台远程机器之间要通讯，为了保证安全，我们可以采用加密等措施，也可以采用SAML来传输，传输的数据以XML形式，符合SAML规范，这样我们就可以不要求两台机器采用什么样的系统，只要求能理解SAML规范即可，显然比传统的方式更好。SAML 规范是一组Schema 定义。可以这么说，在Web Service 领域，schema就是规范，在Java领域，API就是规范。

　　IdP与SP通过SAML消息传送用户的身份和属性等信息。SAML消息定义了2种重要的语句：(1)身份验证语句，关于该主题在何时何地、使用何种身份进行过验证的。SAML提供了超过20种不同身份验证方法的详细定义。身份验证语句支持SSO，其中IdP代表SP进行登录。(2)属性语句，包含了与主题有关的属性。属性语句中典型的属性是组和角色。

　　安全是所有Web项目在设计时都要考虑的一个重要因素。无论是选择短口令，决定何时使用SSL加密HTTP会话，还是通过自动登录cookie来识别用户，都经常要付出重大的设计努力，以保护用户的身份信息和他们可能存放于Web站点的其他资料。糟糕的安全性可能带来公关灾难。当终用户努力保持对其个人信息的控制时，他们要面临令人迷惑的隐私政策，需要牢记众多站点的不同口令，以及遭遇“钓鱼式攻击”事件。在宏观层次上，数字身份引起了许多复杂的技术和社会问题，业界一些团体如Liberty Alliance和IdentityGang都正试图通过开发新的技术标准来解决它们。在较小的规模上，可以使用一些工具来为用户提供更好的安全性。请考虑口令管理问题。用户访问他们保存个人资料的Web站点，在可以存取他们的资料之前必须经过验证。通过验证来鉴别用户，确保他们是所声称的用户。进行验证简单方式是使用口令。然而，若每个站点都需要各自的一套口令，用户将有难以控制的大量口令。

　　1998年微软首先尝试通过其Passport network提供该问题的解决方案。Passport使得任意Web站点使用用户提交给Passport的个人资料（如用户名、地址、信用卡号）成为可能。Passport是单点登录（single sign-on，SSO）的次电子商务尝试。它没有流行起来，部分原因是由于人们对系统封闭性的担心。然而，SSO的理念非常引人注目，许多开放标准和商业计划都追随Passport其后。通过SSO，某个Web站点可以与其他站点共享用户身份信息。 SSO对于使用应用服务提供商（Application Service Provider，ASP）软件服务的企业特别有用。ASP在自己的服务器上宿主应用程序，出售其访问权作为服务。公司可以在它的标准目录服务器里管理自己的用户和口令，然后通过SSO授予用户访问ASP应用程序的权限。SSO允许公司管理自己用户的信息，不必为每一员工维护多个用户账号。对用户来说，SSO的好处在于他们可以在多个应用程序中使用一个用户名和口令，并且在应用程序之间切换时无需重新验证。SSO不仅仅用于Web应用程序，它可用于任何类型的应用程序，只要有安全地传送身份信息的协议。这种通信方式的开放标准就是安全性断言标记语言（SAML）。

　　3 Shibboleth在本系统中的作用

　　(1)系统将基于Shibboleth的框架进行开发，但不完全使用Shibboleth，需要根据用户的实际需求对其进行改造。

　　(2)Shibboleth构成跨域统一身份系统的部分，包括IdP、SP和WAYF组成的整个跨域统一身份系统的架构。

　　(3)通过将Shibboleth的IdP组件与各个学校的统一身份系统集成，将身份数据的管理和身份凭据的交给各个学校自身的统一身份系统。跨域中心只是作为跨域的索引，并不维护任何身份数据。

　　4 跨校统一身份系统的实现

　　4.1 跨校统一身份系统设计

　　该身份系统可分为3个子系统，身份提供方IdP(Identity Provider)、服务提供方SP(Service Provider)和身份联盟中心FC(Federation Centre)。这3个子系统在实现联盟时，工作原理与Shibboleth基本相同。下面从实现用户身份联盟的角度介绍这3个子系统的结构、工作机制以及交互方式。

　　4.1.1 身份提供方(IdP)

　　IdP是负责用户身份和提供用户、属性信息的实体，它需要维护3个模块，即单点登录系统、数据库系统和Shibboleth的IdP组件。

　　4.1.1.1 单点登录系统

　　单点登录系统(Single Sign-On Authentication System)是源组织的SSO系统，负责响应用户的身份请求并生成SSO Token[4]。加入身份联盟的先决条件就是源组织已经可以实现统一身份，在此基础上，源组织无须对SSO系统做出变动。目前使用较多SSO系统有SUN、Oracle、IBM、Microsoft等厂商推出的统一身份系统，身份联盟系统都将提供很好的兼容。

　　4.1.1.2 数据库和用户属性数据库

　　数据库(Authentication DB)是源组织SSO系统的一部分，为SSO提供数据并直接服务于单点登录系统。

　　用户属性数据库(User DB)主要为Shibboleth的IdP组件服务，它存储了身份联盟系统所需要的用户属性信息。

　　4.1.1.3 Shibboleth的IdP组件

　　Shibooleth的IdP组件主要工作单元分为句柄服务器HS(Handle Server)和属性中心AA(Attribute Authority)2个部分。

　　(1)句柄服务器(HS)

　　用户通过源组织的SSO后，HS根据用户浏览器中cookie值颁发身份联盟的句柄作为用户在联盟中的身份凭据。获得句柄的过程既可以通过用户浏览器的Browser/POST和Browser/Artifact方式来实现，也可以通过SAML中的身份验证断言(Authentication Assertion)来实现。SAML定义了<samlp:AuthenticationQuery或<samlp:AssertionIDReference>字段的<samlp:Request>消息，通过它可以得到用户身份的断言(Assertion)，从中获取句柄信息。用户获得句柄后就获得了访问联盟中服务提供方的合法身份。

　　(2)属性中心(AA)

　　AA为服务提供方(SP)提供用户相关的属性信息，这些信息又可分类为用户固有属性信息和用户访问策略信息。用户固有属性信息存储在用户属性数据库(User DB)的数据中；用户访问策略信息则是由属性中心的属性释放策略ARP(Attribute Release Policy)提供的XML配置文件，包含了指定用户是否可以访问指定资源的决策信息。ARP文件定义了一系列的默认策略，同时也支持用户配置策略，用户配置策略的制定工作将统一交由身份联盟中心(FC)负责。

　　4.1.2 服务提供方(SP)

　　SP是提供基于Web的服务、应用或资源的实体，通过安全的途径实现资源的授权访问和个性化服务。主要包含2个模块：mod_shib模块和SHAR模块。

　　4.1.2.1 mod_shib模块

　　mod_shib是Shibboleth用于集成到SP Apache服务器的一个扩展模块，负责根据IdP提供的用户访问策略和本地访问控制策略对资源进行访问控制。

　　4.1.2.2 SHAR模块

　　SHAR(Shibboleth Attribute Requester)是运行在服务提供方服务器上的一个后台程序，负责向IdP请求用户属性相关的信息并处理响应消息。实际上SHAR是与IdP的属性中心AA配合工作的，当SP需要用户属性信息时，SHAR将以通过后获得的句柄(Handle)为凭据，向AA发送属性请求的SAML消息，AA返回属性查询结果，交由SHAR解析作为mod_shib模块实现访问控制的依据。

　　4.1.3 身份联盟中心(FC)

　　FC的主要功能是用于用户的源组织选择，即当用户访问非源组织资源需要时，将由FC提供源组织定位服务。该功能主要基于Shibboleth的Service Discovery组件，也可称为WAYF服务。另外，本项目中的FC还根据需求提出了资源注册、计费、审计等辅助功能。

　　WAYF服务在Shibboleth结构中是一个可选组件，采用集中的方式让用户选择自己所在的源组织。

　　WAYF服务必须支持Shibboleth的请求方式，即浏览器Browser/POST和Browser/Artifact请求方式或者SAML请求方式，目的是为了协调源组织的SSO服务和身份联盟系统中的SSO服务。WAYF实际上充当了各源组织SSO服务的中介，使各源组织的SSO在整个身份联盟系统中都具有有效性。

　　4.2 跨校统一身份系统框架

　　4.2.1 全局架构设计

　　(1)每个高校都具有双重身份：既是服务提供者(SP)，又是身份提供者(IdP)。

　　(2)存在一个Discovery服务(即WAYF服务)，当用户没有经过而访问SP时，由Discovery确定用户应该到哪个IdP去进行身份验证。

　　整体逻辑架构[5]说明如图2所示。

　　4.2.2 单一高校内部的系统架构设计

　　为了更清楚地说明整个逻辑架构，图3所示为各个高校的内部逻辑架构图。

　　高校内部逻辑架构[6]说明：

　　(1)高校中的IdP基于原有的身份系统，在原有系统基础上加入2个IdP组件：凭据和属性凭据。

　　(2)高校的SP提供并保护高校的受控资源，在受控资源之上增加3个SP组件：断言接受器、属性请求器和访问控制器。1个SP可以保护多个受控资源。

　　4.2.3 联盟过程

　　4.2.3.1 用户未登录时访问高校A的资源(系统视角)

　　场景：用户次访问高校A的受控资源如图4、图5、图6所示。

　　用户访问某一高校受控资源步骤如下：

　　(1)用户向高校A提出访问请求。

　　(2)高校A的断言接受器发现该用户未，将请求重定向给联盟中心的WAYF服务器。

　　(3)WAYF服务器将学校选择界面发送给用户，让用户选择所能的IdP。

　　用户访问某一高交的Jdp步骤如下：

　　(1)用户选择高校A后，提交给WAYF。

　　(2)WAYF重定向到高校A的服务。

　　(3)高校A的服务发现用户尚未登录，将请求定向到SSO服务。

　　(4)SSO服务向用户发出高校A的登录界面。

　　用户进行身份的过程步骤如下：

　　(1)用户输入用户名口令，向高校A的IdP登录。

　　(2)高校A的SSO服务对用户，通过后生成Ticket(用户A通过后的证明)，交给浏览器。

　　(3)请求重定向到高校A的服务，该服务到SSO服务上去验证之前生成的Ticket。

　　(4)SSO服务验证Ticket，通过后将用户的userId交给服务。

　　(5)服务将userId交给凭据。

　　(6)凭据为该用户产生一个nameId，这是整个联盟过程中用户的标识，并将该nameId返回给服务。

　　(7)服务将nameId发还给浏览器，浏览器再次访问高校A的SP。

　　(8)高校A的断言接受器接受后用户的请求，传给属性请求器。

　　(9)属性请求器根据来访用户的nameId，向该用户的IdP的属性凭据请求用户的属性。

　　(10)高校A的属性凭据根据该nameId从凭据处获得用户真实的userId。

　　(11)属性凭据根据获得的userId从用户数据库中获得用户身份信息的属性值，将属性值返回给高校A的属性请求器。

　　(12)高校A的属性请求器将属性值发送给访问控制器。

　　(13)访问控制器根据用户的属性决定用户可访问的受控资源，并将结果返回给用户。

　　4.2.3.2 用户未登录时访问高校A资源(用户视角)

　　用户可视过程如图7所示。

　　访问高校A资源的整个过程如下：

　　(1)用户向高校A访问受控资源。

　　(2)用户收到回复，要求其选择所在的高校。

　　(3)用户选择其所在的高校。

　　(4)用户收到其所在高校的登录页面。

　　(5)用户填入用户名密码，并提交。

　　(6)用户获得所需要的受控资源。

　　本文参考Shibboleth的架构，完成了跨校身份联盟系统的设计方案，实现用户“异地访问—本地”的功能，避免了异地的繁琐，简化了业务流程。身份联盟各子系统交互采用SAML标准，有效地保证了系统通信的安全，保障了用户的隐私，很好地满足了应用管理的需求，为高校间的合作和信息交流提供了一个良好的平台。