Shibboleth开源框架的理解

理解 Shibboleth

Shibboleth 是一个免费，开源的 Web 单点登录系统，具有丰富属性的开放标准，主要是基于 SAML 协议的。这是一个联合系统，支持安全访问跨安全域的资源。有关用户的信息是从身份提供者（ IDP ）发送到服务提供商（ SP ），它准备对受保护的内容或应用信息进行保护。所谓的联盟，而不是一个纯粹的技术建造，通常可以用来帮助提供一个可扩展的方式信任对方。

一、 Shibboleth 基础知识

1.1    他们是如何组合在一起的？

        Shibboleth 有两个主要的部分，一个是身份提供商（ IDP ， identity provider ），另外一个是服务提供商（ SP ， service provider ）。身份提供者（ IDP ）提供信息的服务用户，服务供应商（ SP ）收集有关用户的信息，以保护资源。一个典型的例子， Web 浏览器访问一个受保护的资源，在他们的身份提供商（ IDP ）进行身份验证，并最终返回在受保护资源处重新登录。

        这实际上是如何发生的，以及他是如何用 IDP 和 SP 的配置进行配置的？其他部分涉及到什么？

1.1.1          用户访问受保护的资源

       一个用户试图访问受保护的资源，造成 SP 去拦截这个请求。资源保护的地址可以在 Web 服务器本身的配置文件中定义，例如在 httpd.conf 或者在 shibboleth2.xml （或者单独文件）文件中用 <RequestMap> 进行定义。

1.1.2          服务提供商 SP 确定身份提供商 IDP 和问题验证请求（ SP Determines IdP and Issues Authentication Request ）

       在这个保护配置的基础之上 SP 将要选择一个 SessionInitiator 使用，而这又是决定哪个 IDP 用户将要被指定或使用什么协议为基础。他们彼此之间提供的信号通过 SAML 的元数据交换。（ The SP will select a SessionInitiator to use based on this protection configuration, which in turn is responsible for determining which IdP the user will be referred to and what protocol to use. The providers signal their profile preferences to one another through the exchange of SAML metadata . ）

       确定要使用的 IDP 的过程称为 IDP 发现（ Discovery ） , 并且可以包括一个配置选项，各种基于 Web 的交互， cookies, 以及其他技术。一个 SessionInitiator 可能会提供一个文本输入框，是指用户在本地或者远程部署的发现服务（ DS, Discovery Service ） , 或者根据资源的要求选择一个固定的 IDP 。

       在一些旧配置中， SP 可能使用老式的发现（ Discovery ）机制被称为“ WAYF ”服务。在这种情况下，验证请求被假定为一个旧的 Shibboleth 1.x 的要求，并颁发给 WAYF 本身，然后一旦做出选择将发送请求到 IDP 。这种方法仅限于 SAML 的 1.x 中使用，不与其他大多数 SAML 的实现互操作，而不是新安装的建议。

通过 SP 的 Cookie 设置

在这一步， SP 将保留原始资源的使用“继电器状态（ relay state ）”的机制，这是由一个 <SessionInitiator> 元素上面的 relayState 属性配置的。默认的机制依赖于一个 cookie ，并发送一个 cookie 的状态管理，包含客户端资源的 URL 以及用于为 IDP 或 DS/WAYF 准备的请求。

（ During this step, the SP will preserve the original resource requested by the browser using a "relay state" mechanism, which is configured by a relayState property on the <SessionInitiator> element. The default mechanism relies on a cookie, and sends a state management cookie containing the resource URL to the client along with the request prepared for the IdP or DS/WAYF. ）

1.1.3          IDP 端进行用户验证

作为上一步的结果一个验证请求将要由 SP 发送到 IDP 。这个请求的格式取决于协议和由 SP 选定的绑定 / 规则（ binding/profile ）。身份验证请求都是通过浏览器，客户端重定向（通过 GET 或 POST ）到一个端点，对这个 IDP 通常被称为“单点登录服务”。

IDP 检查这个请求并且决定在基于 SP 在 relying-party.xml 文件中既定的规则如何去验证这个用户并且验证通常在 < LoginHandler > 元素和 login.config 文件中进行 。用户被重定向到已经选定的登陆处理程序中，验证（或试图）使用选择的方法，并且最终被控制传回到他们用户名设置的处理程序。（ The IdP examines the request and decides how it would like to authenticate the user based on rules established for the SP in relying-party.xml and authentication in general in <LoginHandler> and login.config . The user is redirected to the selected login handler, authenticates (or tries to) using the method selected, and eventually control passes back to the profile handler with their username set. ）

用 IDP 设置 / 读取 Cookie (Cookie(s) Set/Read by IdP)

通常情况下， IDP 在验证过程中将尝试读取或者设置一个或者更多的 cookies 序列，但是根据不同形式身份验证的细节变化。在一般情况下， IDP 将建立一个会话（ session ） cookie, 以便跟踪客户端的请求，通过处理步骤的进度，以及为了 SSO 的目的维持较长时期的交往。另外 cookie 可以根据登陆处理程序的使用参与到验证的过程中。

1.1.4          IDP 回应问题至 SP （ IdP Issues Response to SP ）

       IDP 现在使用主题的名称， SP 和具有约束力的协议 / 专选选择决定将什么样的信息发送给 SP 和如何包装它。

       首先 IDP 用属性解析器收集一个用户的属性设置。它收集所有从后端传来的用户数据，如果有必要把它转换，对每个属性附加编码器。

       这些属性是通过属性过滤器，它可能将消减在响应中包含的信息。最经常发布的属性集将依赖 SP 和 principal 。这将保护用户的隐私。由此产生的信息可低至“验证成功的人（ someone authenticated successfully ）”，或者你能发现任何你可以想像到的属性。用户信息被打包成一种合适的形式，最终尽早的用编码器连接响应，通常用一个 SAML 断言。这个断言可能被用 IDP 的密钥进行签名，在一个 SAML2.0 断言，为了安全和隐私用 SP 的密钥加密。断言被放置在 response 中，也就是通过客户端浏览器返回到 SP ，被称为断言消费服务的端点。

1.1.5          返回到 SP

       浏览器从 IDP 提供了一个响应 (response) 到 SP 的断言消费服务端点。 ACS 执行解密这个消息，如果有必要的断言解密，并执行各种安全检查。如果一切正常，那么 SP 将从这个消息里面解压属性和其他的信息并创建一个新的用户 session 。属性被转换成用 SP 的 AttributeExtractor 可被缓存的形式，通过一个 AttributeFilter ，并且并将这些属性以及其他有关的信息缓存到一个新的 session 中。

       一旦 session 被创建，如果有的话， SP 决定通过检查 IDP 返回的 ”relay state” 信息向任何浏览器发送。

由 SP 读取 Cookie （ Cookie Read by SP ）

The "relay state" information returned by the IdP, will have been created by the SP and by default will point to a specially named cookie that should accompany the authentication response supplied to the ACS endpoint in this step.

最后， SP 将重定向浏览器到确定的资源的位置。

Cookie Set by SP
The SP will associate the browser with the newly created session by sending a cookie containing a session key to the client as part of the redirection to the resource.

1.1.6          返回到受保护的资源

       在最后一步，浏览器被重定向到受保护的资源在步骤 1 中访问，但是这次发生的访问是在存储在 SP 的 SessionCache 中的一个会话环境中访问的。

Cookie Read by SP
The cookie containing the session key set in the previous step is expected to accompany all subsequent requests for protected resources. This is why it's essential that the ACS endpoint and resource location share a virtual host; if they do not, the session cookie set in the previous step won't be returned by the browser, and looping typically results.