基于Shibboleth的可信数字化校园架构研究

基于Shibboleth的可信数字化校园架构研究王怀烨1,沈富可2（华东师范大学计算机科学技术系，上海200241）摘要:Shibboleth系统是一个在多组织的范围内实现单点登录的系统，它的特点是基于标准和开源。本文在介绍Shibboleth系统架构的基础上，在实验室环境下搭建了一个Shibboleth系统的实例。结合该实验实例以及Shibboleth系统的特点，试图从部署、单点登录、访问控制和安全性四个方面实现基于Shibboleth系统的可信数字化校园架构。关键字:Shibboleth系统;单点登录;身份提供者;服务提供者;服务发现者TheResearchonReliableDigitalCampusArchitecturebasedonShibbolethWANGHuai-ye1,SHENFu-ke2（DepartmentofcomputerscienceandtechnologyEastChinaNormalUniversity,Shanghai200241）【Abstract】TheShibbolethSystemisastandardsbased,opensourcesoftwarepackageforwebsinglesign-onacrossorwithinorganizationalboundaries.BasedontheintroductionofShibbolethsystem’sarchitecture,acaseofShibbolethsystemwassetupinthelaboratory’senvironment.CombiningthiscasewiththecharacteristicsofShibbolethsystem,fouraspectsrelatedtoReliableDigitalCampusArchitecturebasedonShibbolethwerebeimplemented,includingdeployment,singlesign-on,accesscontrolandsecurity.【Keywords】Shibbolethsystem;singlesign-on;identityprovider;serviceprovider;discoveryservice1Shibboleth系统架构1.1概述Shibboleth系统是由MACE(MiddlewareArchitectureCommitteeforEducation)领导开发的一个项目。其目的是开发一个基于标准的体系结构、策略框架及一套开源软件，以用于支持组织间的、需要访问控制的Web资源共享。Shibboleth系统从1998年开始开发，在2003年发布了1.0版，2008年3月发布了2.0版。1.2Shibboleth系统组件Shibboleth系统由身份提供者（identityprovider，IdP）、服务提供者（serviceprovider，SP）以及可选的服务发现者（discoveryservice，DS）所组成。1)IdPIdP主要负责用户的认证和用户属性的传递，并在SP生成认证请求时，生成认证应答，该应答连同用户属性将会被一起传递给SP。IdP本身并不存储用户信息，而依赖于目录服务存储用户信息。2)SPSP主要负责管理被保护的资源，并根据IdP传递过来的认证应答和用户属性执行访问控制。3)DSDS主要负责IdP的发现，并在SP生成认证请求时，提供可以选择的IdP列表。它是一个可选择的组件。主要应用在多IdP的环境下。三者的交互流程[1]如图1所示：作者简介：王怀烨（1984-），男，上海松江人，硕士研究生，主要研究方向：计算机网络；沈富可（1967-），男，山东莱西人，博士研究生，主要研究方向：计算机网络Email：[e-mail]；[e-mail]图1SP,IdP与DS的交互流程1)用户访问被SP保护的资源2)SP生成认证请求，并把用户重定向到DS3)用户重定向到DS4)用户选择IdP，认证请求被重定向到用户所选择的IdP5)用户重定向到所选择的IdP进行认证6)IdP根据用户提供的信息生成认证应答7)SP根据收到的认证应答来进行访问控制2Shibboleth系统实例的搭建为了更好地了解和掌握Shibboleth系统，我们在实验室环境下搭建了一个Shibboleth系统的实例。该系统由两个IdP，两个SP以及一个DS构成。实验所用的Shibboleth系统版本为2.0版。2.1实验环境1)IdP1操作系统：WindowsXPSP2域名：idp1.ecnu.edu.cn环境：JDK5.0Tomcat5.5.26OpenLDAP2.2.29表1IdP1中目录服务的条目uid（用来唯一标识用户）ou（用户所属机构）title（用户身份）ZhangHaiLIBAdminLiMingLIBUserLiuXinNICUser2)IdP2操作系统：Windows2003SP1域名：idp2.ecnu.edu.cn环境：JDK5.0Tomcat5.5.26Windows2003自带的ActiveDirectory表2IdP2中目录服务的条目cn（用来唯一标识用户）ou（用户所属机构）title（用户身份）用户1服务提供者资源身份提供者服务发现者234567WangHaiCSAdminLiHongEDUUser3)SP1操作系统：WindowsXPSP2域名：sp1.ecnu.edu.cn环境：IIS5.14)SP2操作系统：WindowsXPSP2域名：sp2.ecnu.edu.cn环境：IIS5.15)DS操作系统：WindowsXPSP2域名：ds.ecnu.edu.cn环境：JDK5.0Tomcat5.5.262.2实例部署1)sp1.ecnu.edu.cn下有一资源，URL为sp1.ecnu.edu.cn/TestShib，其访问控制权限为只有ou为LIB且title为admin的用户才可以访问。2)sp2.ecnu.edu.cn下有一资源，URL为sp2.ecnu.edu.cn/TestShib2，其访问权限为任意，只要通过认证的用户都可以访问。3)SP1与IdP1属于同一个组织ECNULIB，他们的用户都注册在IdP1的目录服务中，用户信息如表1所示。SP2与IdP2属于另一个组织ECNUDEP，他们的用户都注册在IdP2的ActiveDirectory中，用户信息如表2所示。3对基于Shibboleth的可信数字化校园架构的研究通过上述实例的部署和运行，并结合Shibboleth系统的特点，从以下四个方面对基于Shibboleth的可信数字化校园架构进行了研究和分析。3.1部署3.1.1安装基于Shibboleth的可信数字化校园架构中的所有组件都可以在Windows或者Linux平台下安装，但由于Shibboleth声明现阶段官方支持的Linux版本只有CentOS4和5的32位或64位版本，实验中统一使用了Windows平台。IdP与DS的运行需要Javaservlet容器的支持，实验中所使用的servlet容器是Shibboleth官方推荐的ApacheTomcat。另外，IdP的运行还需要目录服务的支持。IdP本身并不存储用户信息，而是需要借助外部的目录服务来进行存储。实验实例中的两个IdP分别使用了OpenLDAP和ActiveDirectory。其中，OpenLDAP是跨平台的，可以在Linux和Windows平台下使用；ActiveDirectory则是Windows2003自带的目录服务。3.1.2配置架构中各个组件的配置主要是依靠它们各自的配置文件和元数据文件[2]，它们都是XML格式的文件。配置文件主要用来配置组件本身的一些属性，而元数据文件并不描述组件本身的信息，而是用来描述Relying-Party的信息。Relying-Party在Shibboleth系统中代表可信方。举个例子来说，一个最简单的Shibboleth系统，只有一个IdP和一个SP，IdP凭什么响应SP生成的认证请求？SP凭什么信任IdP生成的认证应答？当SP和IdP互为Relying-Party时，即SP的元数据文件描述了IdP的相关信息，IdP的元数据文件描述了SP的相关信息，SP与IdP的信任关系就建立起来了，这也就组成了一个最小的可信联盟。配置文件采取本地载入的方式，元数据文件则采取本地载入或远程载入两种方式，可以根据需要灵活配置载入方式。如果应用范围较小，比如实验实例中只涉及到两个SP和两个IdP，则可以采取本地载入的方式来提高系统的响应速度。如果应用范围较大，比如一般的校园网都会涉及到多个院系和管理部门，则可以采取远程载入的方式，将元数据文件统一存放在一台服务器上，方便集中管理。当然，为了增加系统的冗余性，一般都会采取同时配置本地和远程载入方式。3.2单点登录随着数字化校园建设的不断深入，越来越多的服务被数字化、网络化，我们完全可以在网上办理几乎所有与我们学习生活相关的业务，如收发邮件，维护个人信息，使用图书馆数字资源。在享受数字化校园所带来的便利的同时，我们也会经常遇到如下情况：去学校邮箱收发邮件，首先需要输入用户名和密码来进行登录。去学校公共数据库维护个人信息，也首先需要输入用户名和密码来进行登录。访问学校图书馆数字资源，还是需要首先输入用户名和密码来进行登录。使用不同的资源和服务就需要一次额外的登录，这显然与数字化校园所倡导的方便、快捷不相符合。单点登录的思想就是用户只需登录一次，就可以访问多个不同域的资源和服务，无需再重复登录。微软的.NETPassport是一个比较典型的单点登录系统，它通过建立中心服务器，使用户拥有一个全网唯一的身份来实现单点登录。而Shibboleth系统则使用分布式方式，在不同的IdP和SP之间通过联盟的方式建立信任关系，实现单点登录。以实验实例来说，IdP1和SP1属于一个组织ECNULIB，IdP2和SP2属于另一个组织ECNUDEP，IdP1与IdP2的目录服务中注册用户的交集为空集。IdP1和IdP2所加载的元数据文件必须包含SP1和SP2的相关信息，SP1和SP2所加载的元数据文件必须包含IdP1和IdP2的相关信息，DS所加载的元数据文件必须包含IdP1、IdP2、SP1和SP2的相关信息。这样，IdP1、IdP2、SP1、SP2、DS之间就建立起了一个包括五个实体的可信联盟[3]。以此类推，在基于Shibboleth的数字化校园架构中，每个IdP必须加载描述所有SP的元数据，每个SP则必须加载描述所有IdP的元数据，DS则必须加载描述所有SP和IdP的元数据。仅仅这样，Shibboleth系统还无法实现单点登录，描述SP和IdP的元数据文件中还需要添加描述单点登录的元素[4]：1)描述IdP的元数据文件必须包括IDPSSODescriptor元素，该元素所包含的子元素SingleSignOnService描述了IdP支持单点登录所需要的句柄。SingleSignOnService子元素，用来配置IdP处理认证请求的句柄。它有两个非常重要的属性：Binding和Location。其中Binding属性指定了该SingleSignOnService所绑定的协议，Location属性则指定了IdP在收到认证请求后，处理该认证请求的位置。每个IDPSSODescriptor元素中必须至少包含这样一个SingleSignOnService：Binding属性为urn:mace:shibboleth:1.0:profiles:AuthnRequest，其相应的Location属性指定处理AuthnRequest的位置。在描述SP的元数据文件中，通常有不止一个SingleSignOnService子元素，这些SingleSignOnService子元素对应处理如