OAuth2 + Shibboleth 集成

基于 Shibboleth 的跨校认证框架很好的解决的了分布式认证的问题,并且为基于用户属性的授权提供了很好的方案。然而其对于应用的授权却比较简单,是基于认证节点的分布式授权,缺乏中心化的授权管理。因此,各认证节点向应用所传输的身份数据也缺乏标准,数据结构散乱,需要二次整合。分布式的框架架构必须要存在中心化的管理,否则必然会成为一盘散沙。

因此我们需要一个中心化的授权管理机制,来统筹应用节点与认证节点之间的对接。同时又不能破坏现有的分布式认证框架。我们给出的方案是 Oauth2+Shibboleth。通过Oauth2进行授权管理,通过Shibboleth进行分布式的认证。其框架如图所示

 

如图所示,认证中心作为身份认证的统一交换平台,对接应用市场和跨校认证联盟框架。应用通过Oauth2的开放接口进行授权,授权时调用统一认证接口——即跨校认证接口对接Shibboleth框架进行分布式认证。通过认证传递用户属性数据,这些数据在身份认证中心的平台中进行整合清洗,封装为统一的数据标准格式,以API接口的形式发布予以应用调用。

认证中心采取的Oauth2授权模式,是互联网主流的授权方案,便于应用的快速接入,非常有利于推广。同时数据通过先流入认证中心,再授权给应用的模式,提供了数据清洗的契机,有利于数据结构的标准化,这对于应用的对接推广也是极有帮助的。基于此,我们就能够通过认证中心构建一个开放的授权平台,类似于微信/微博/人人网等开放授权平台,从而形成一个区域教育信息化的生态圈。

Shibboleth 框架

Shibboleth是一种标准化的开源软件,用于组织成员之间通过web进行单点登录。Shibboleth支持节点之间的个体在访问受保护的资源时,提供安全、隐私的身份认证服务。

其主要由三个部分组成:

(1)IDP(Identity Provider,身份提供者)

身份提供端:主要作用是向资源提供者提供用户的属性,以便使资源服务器根据其属性对其访问操作进行授权和响应。

(2)SP(Service Provider,资源提供者)

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

(3)WAYF(Where Are You From,认证中心。Shibboleth 2.0之后更名为DS,即DiscoveryService,但是习惯上依然称为WAYF)

下图展示的是上海教育系统跨校认证联盟的逻辑架构

下图展示了用户在登陆跨校认证系统时的系统逻辑示例:

(1)用户使用浏览器访问资源系统

(2)资源系统如果没有找到所需要的授权信息,将用户重定向到DS 服务器;

(3-4)在DS服务器上,用户从参与跨校身份认证的机构列表中找到他的源组织;

DS服务器把用户重定向到位于源组织上的IdP服务器上;

(6-7)根据本地的规则和方法,对用户进行认证。

(8)  一旦认证通过,句柄服务(Handle Service)就会为用户产生一个不透明的句柄(Handle),并将句柄传递给资源系统。句柄就是用户需要提交给资源系统的认证信息。

(9)       资源系统再把句柄与资源系统的地址一起发送给位于源组织的属性管理器,属性管理器检查用户的哪个属性释放策略可以应用于资源系统。

(10)     属性管理器返回允许发送给资源管理器的属性。在资源系统内,获得的属性要根据属性接受策略进行核实,决定是否可提供访问。

上海教育认证中心

根据上海教育信息化顶层设计概要“一网三中心两平台”的总体需求,上海教育认证中心(以下简称EAC)是三大中心之一,它将实现基于多特征及多身份的教育对象全周期一体化认证信息管理。在各区县、各学校乃至各学段均可拥用各自符合身份标准信息集的统一身份认证管理域的前提下,EAC将通过上海教育认证中心建设,实现多协议支持的跨校联盟,一方面实现身份终身化和成长跟踪,识别学生成长过程,并成为数据分析的重要依据;另一方面实现与互联网主流标准的兼容,成为互联网领域重要的身份来源,服务于教育系统内外的应用。

上海教育认证中心向各子域提供云端服务方式和IdP代理方式两种接入方式。云端服务方式即所有IdP、LDAP、用户认证基本信息都在上海市教委云端,由教委统一管理并保障安全,子域方管理员可定期上传用户基本信息,用户需自行通过微信公众号“上海教育认证中心”进行激活并获取初始口令才能使用;IdP代理方式即将IDP部署在子域内部,IdP、LDAP及子域用户认证信息都在子域内,由子域自行管理维护。

上海教育认证中心向各应用提供 SAML 原生,Shibboleth SP 代理, Oauth2 三种对接方式。SAML 原生提供基于 SAML2 的原生接入方式;Shiibboleth SP 代理基于 SAML2 原生接入的代理服务,可以根据实际需求定义代理服务的 API; Oauth2 提供基于 Oauth2 的接入方式和对应的 API。