Shibboleth开源框架的理解
理解 Shibboleth
Shibboleth 是一个免费，开源的Web单点登录系统，具有丰富属性的开放标准，主要是基于SAML协议的。这是一个联合系统，支持安全访问跨安全域的资源。有关用户的信息是从身份提供者（IDP）发送到服务提供商（SP），它准备对受保护的内容或应用信息进行保护。所谓的联盟，而不是一个纯粹的技术建造，通常可以用来帮助提供一个可扩展的方式信任对方。
??????? Shibboleth有两个主要的部分，一个是身份提供商（IDP，identityprovider），另外一个是服务提供商（SP，service provider）。身份提供者（IDP）提供信息的服务用户，服务供应商（SP）收集有关用户的信息，以保护资源。一个典型的例子，Web浏览器访问一个受保护的资源，在他们的身份提供商（IDP）进行身份验证，并最终返回在受保护资源处重新登录。
??????? 这实际上是如何发生的，以及他是如何用IDP和SP的配置进行配置的？其他部分涉及到什么？
在这一步，SP将保留原始资源的使用“继电器状态（relay state）”的机制，这是由一个<SessionInitiator> 元素上面的relayState属性配置的。默认的机制依赖于一个cookie，并发送一个cookie的状态管理，包含客户端资源的URL以及用于为IDP或DS/WAYF准备的请求。
relayState property onthe <SessionInitiator>element. The default mechanism relies on a cookie, and sends a state managementcookie containing the resource URL to the client along with the requestprepared for the IdP or DS/WAYF.）
作为上一步的结果一个验证请求将要由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 onrules established for the SP in relying-party.xmland authentication in general in <LoginHandler> and login.config.The user is redirected to the selected login handler, authenticates (or triesto) using the method selected, and eventually control passes back to theprofile handler with their username set.）
用IDP设置/读取Cookie (Cookie(s) Set/Read by IdP)
通常情况下，IDP在验证过程中将尝试读取或者设置一个或者更多的cookies序列，但是根据不同形式身份验证的细节变化。在一般情况下，IDP将建立一个会话（session）cookie,以便跟踪客户端的请求，通过处理步骤的进度，以及为了SSO的目的维持较长时期的交往。另外cookie可以根据登陆处理程序的使用参与到验证的过程中。
最后，SP将重定向浏览器到确定的资源的位置。
Cookie Set by SP
The SP will associate the browser with the newly created session by sending acookie containing a session key to the client as part of the redirection to theresource.
1.1.6?????????返回到受保护的资源
?????? 在最后一步，浏览器被重定向到受保护的资源在步骤1中访问，但是这次发生的访问是在存储在SP的SessionCache中的一个会话环境中访问的。
Cookie Read by SP
The cookie containing the session key set in the previous step is expected toaccompany all subsequent requests for protected resources. This is why it'sessential that the ACS endpoint and resource location share a virtual host; ifthey do not, the session cookie set in the previous step won't be returned bythe browser, and looping typically results.