1.2.1 Shibboleth

什么是 Shibboleth

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

Shibboleth 组件广泛的用于组织联盟内的认证，主要使用SAML语言构建联盟内的单点登录和属性交换的框架。当一个用户在他自己的组织（子域）内完成认证后，这个组织（IDP）将释放其所允许最小范围内的身份属性给资源提供者（SP）,从而允许用户可以访问上SP面的资源。Shibboleth 提供可扩展的隐私保护功能，即允许 IDP 自行控制其释放给不同SP的属性类别和数量

Shibboleth 项目最早在 2000 年在 Internet2 上成立，之同年和 SAML 工作组开始合作。 Shibboleth 1.0 在 2003 年发布，并很快的在教育界和研究机构得到了推广。随着 2005 年 SAML2.0 和随后Shibboleth 2.0 的发布，由 Shibboleth 倡导的 SAML 逐渐成为多边，元数据驱动方法的标准。

Shibboleth 是一个开源软件并在 Apache 软件许可证下发布。更多的组件相关信息可以在项目的相关页面上找到。（https://wiki.shibboleth.net/confluence/display/SHIB2/Home）

Shibboleth® 是 Internet2® 的注册商标

Shibboleth 的工作原理

在核心技术上，Shibboleth和其他单点登录系统的工作方式没什么不同。主要的区别在于Shibboleth在提供单点登录的同时，还尽量得保护了用户的隐私。

一个Web-SSO系统的主要元素如下：

• 浏览器：代表SSO流程中的用户
• 资源：用户所希望访问的受限内容
• 身份提供者（IDP）：认证用户
• 资源提供者（SP）：为资源提供SSO

通常的 SSO 流程

1：用户访问资源 用户尝试访问一个被保护的资源。资源监视器会判断用户是否拥有一个有效的 session，如果没有则引导他转向 SP 来开启以 SSO 的流程。

2：SP 发起认证请求 用户访问 SP，SP 发起认证请求，并将用户重定向到用户所在的 IDP 进行认证。SP 组件一般会和资源安装在一台服务器上。

3：IDP 上的用户认证 当用户被重定向IDP服务器上时，IDP 会检查用户是否已经有一个存在的session（即认证过）。如果有的话，直接跳下一步。如果没有，则在 IDP 上发起用户认证（比如通过用户名和密码），然后进行下一步

4：IDP 发起认证 response 用户认证通过后，IDP 产生一个认证 response，并将其发送给 SP，同时用户返回到 SP。

5：SP 检查认证 response 当用户带着 IDP 的认证 response 回到 SP，SP 将验证这个 response，并为用户创建一个 Session ，并从 response 中提取受限资源所需要的一些信息（比如用户的标识）。然后用户被跳转至资源。

6：资源返回内容 如同第一步，用户现在再一次尝试访问这些受保护的资源，但这一次用户有 session 了，并且资源也知道他们的信息了。因此，这一次资源将回应用户的请求，并返回用户请求的数据。

联邦式的 SSO

如果你听说过 shibboleth，你可能也听说过“联盟”，或者“联邦认证”。上面那些步骤对于所有的单点登系统都是一样的，但是一些系统在设计上要求 IDP 和 SP 在同一个组织内才能工作，同时其他一些在设计上则并不关心这两者在不在同一个组织内。后一种方式被成为联邦认证。

这其实并不算罕见，有时候 SP 会希望同时为多个 IDP 提供服务（比如一些应用希望扩大用户范围，一些资源希望能够为不同组织的研究者共享）。同时一个 IDP 也会希望为多个 SP 提供认证。当一批的 IDP 和 SP 互相达成一致，共同工作，这样的组合就被成为“联盟”

Discovery Server

问题在于，SP 是如何同时与多个 IDP 工作的呢？他怎么知道要把认证的 Response 发给哪个 IDP 呢？

答案是：直接问用户，这就是 IDP Discovery Shibboleth 提供两种可用于 IDP Discovery 的产品。嵌入式 DS(EDS) 和 SP 共同工作，以便于在你的站点上展示 IDP 的选择界面，而集中式 DS(CDS) 则是一个可以独立部署的中央式应用，SP 可以将请求转发给他，来展示 IDP 的选择界面。

我们鼓励 SP 使用 EDS，因为它能带来更好的用户体验。

用户属性

使用 Shibboleth 服务的另一大特点是他能够在从 IDP 接收用户返回的数据。这些数据我们称之为用户属性，他可以是 IDP 上能读取到任何与用户先关的内容，这些对 SP 可能会非常有用。举个例子，这些属性可以式样的：

• 用户的邮箱或者电话号码
• 用户所在的组织
• 用户在组织内的身份（角色）
• 具体所授予用户的权限

保护用于隐私的能力是 Shibboleth 产品的主要考量点之一。IDP 和 SP 都允许部署者自行设置属性过滤规则来实现这个功能。IDP 可以自行控制，对不同 SP 的释放不同的属性，SP 则可以控制哪些属性来自哪个 IDP 的是可以被接受的。

Metadata

另一个问题是如果 SSO 的程序是通过 http 开展的，那么 IDP 和 SP 怎么知道互相通信的 URL 是什么呢？这个功能通过一个描述了 IDP 和 SP 各方面信息的 Metadata 文件来实现。

Metadata 通常包含如下信息

• 一个惟一标识符，我们称之为 Entity ID；
• 一个便于理解的名字和描述
• 一些关于哪些信息需要交付和什么时候需要交付的 url 列表
• 创建和验证消息时所使用密钥

一个联盟的常见功能是发布包含联盟内所有 IDP 和 SP 的 Metadata 集合，并将它分发给每一个参与者。这样当 Metadata 改变的时候，SP 不需要和每个 IDP 联系（反之亦然），只需要发送给联盟即可。

Shibboleth 认证流程

因此一个完整的 Shibboleth 认证流程的示例如下图所示:

• 1 用户首先访问SP请求资源
• 2 未授权的用户，由断言服务重定向至DS服务P
• 3-4 用户选择 IdP
• 5 用户被重定向至IdP
• 6-7 用户向IdP发送身份认证凭据进行认证
• 8 认证通过，IdP向SP发送句柄通知
• 9 SP向IdP发送句柄请求属性，属性规范应符合第五章所描述的属性教官标准。
• 10 IdP根据属性管理所允许的属性集合
• 11 用户完成跨域认证，访问受保护的资源应用