How Shibboleth Works: Basic Concepts翻译

自己翻译的Shibboleth官网的文章“How Shibboleth Works: Basic Concepts”，翻译得有问题的欢迎指出（本人英语四级而已，勿忘）
原文链接：
http://shibboleth.net/about/basic.html

How Shibboleth Works: Basic Concepts
Shibboleth如何工作：基本概念

At its core Shibboleth works the same as every other web-based Single Sign-on (SSO) system. What distinguishes Shibboleth from other products in this field is its adherence to standards and its ability to provide Single Sign-on support to services outside of a user's organization while still protecting their privacy.
Shibboleth的核心内容跟其他的基于互联网（web-based）的单点登录(SSO)系统一样。Shibboleth跟这个类型的其他产品的区别是，Shibboleth坚持标准，以及它提供组织之外的单点登录服务的同时保护它们的隐私。

The main actors in a web-based SSO system are:
基于互联网的单点登录系统包含以下几个主要的角色：

Web Browser: represents the user within the SSO process
Web Browser：在SSO操作中代表用户
Resource: contains access-restricted content that the user wants
Resource： 存储用户想要访问的受限内容
Identity Provider: authenticates the user
Identity Provider: 认证这个用户
Service Provider: performs the SSO process for the resource
Service Provider: 展示SSO对资源的操作

Single Sign-on Steps
单点登录步骤

Step 1: User Accesses the Resource
Step 1: 用户访问资源

The user starts by attempting to access the protected resource. The resource monitor determines if the user has an active session and, discovering that they do not, sends them to the service provider in order to start the SSO process.
用户试图访问受保护资源。资源管理者会判断用户是否有会话存在，如果没有讲请求发送到Service Provider以开始SSO处理流程

Step 2: Service Provider Issues Authentication Request
Step 2: Service Provider处理认证请求

The user arrives at the service provider which prepares an authentication request and sends it and the user to the identity provider. The service provider software is generally installed on the same server as the resource.
Service Provider将认证请求返回给用户，并将用户定位到要求认证的Identity Provider。Service Provider通常情况下与资源安装在统一服务器上。

Step 3: User Authenticated at Identity Provider
Step 3: 用户在Identity Provider上认证

When the user arrives at the identity provider it checks to see if the user has an existing session. If they do, they proceed to the next step. If not, the identity provider authenticates them (e.g., by prompting for, and checking, a username and password) and the user proceeds to the next step.
当用户访问Identity Provider的时候，Identity Provider会检查这个用户是否已经与Identity Provider存在会话。如果有，直接进入下一步。如果没有，Identity Provider会对用户进行认证（例如：检查用户名密码）并且进入下一步。

Step 4: Identity Provider Issues Authentication Response
Step 4: Identity Provider处理认证响应

After identifying the user the identity provider prepares an authentication response and sends it and the user back to the service provider.
Identity Provider认证过用户以后会生成一个响应，用户会随着这个响应重定向到Service Provider

Step 5: Service Provider Checks Response
Step 5: Service Provider检查响应

When the user arrives with the response from the identity provider, the service provider will validate the response, create a session for the user, and make some information retrieved from the response (e.g., the user's identifier) available to the protected resource. After this, the user is sent to the resource.
当用户跟随Identity Provider的响应重定向到Service Provider，Service Provider会验证这个响应的内容，为这个用户建立一个会话，通过响应的内容生成一些信息（例如：用户的身份标识）用于保护资源。然后用户会重定向到资源

Step 6: Resource Returns Content
Step 6: 资源返回内容

As in step one the user is now trying again to access the protected resource but this time the user has a session and the resource knows who they are. With this information the resource decides it's okay to service the user's request and sends back the requested data.
像第一步一样，用户重新访问受保护资源，但是这次这个用户拥有一个会话，因此资源知道这个用户是谁，通过这些信息，资源可以决定响应用户的这个请求，并且返回所请求的数据内容。

Federated Single Sign-on
联盟单点登录

Chances are when you heard about Shibboleth you also heard something about "federations" or "Federated Single Sign-on". If the steps above are the same for any given Single Sign-on system then what is this "federation" stuff, you might ask. As is often the case, the devil is in the details. The above steps are indeed common to all Single Sign-on systems but some of those systems are designed to only work when the identity provider and service provider are in the same organization. Others are designed to work regardless of whether the two components are in the same organization. Implementations that fall into the later category are said to implement Federated Single Sign-on.
当听到关于Shibboleth的时候常常会听到一些关于联盟（federation）或者联盟单点登录（Federated Single Sign-on）的内容。如果任何一个SSO系统中的单点登录实现都是通过以上的那些步骤（Step1 - Step6）实现的时候，所有的这些系统就构成了一个联盟（federation）。As is often the case, the devil is in the details（翻不出来 - -！）。以上这些步骤在所有的SSO系统中是很常见的，但是这些系统设计的前提是Identity Provider和Service Provider都在一个组织内。另外一种设计是Identity Provider和Service Provider不要求在同一组织内。后一种实现就是联盟单点登录的实现方式。

It shouldn't be a surprise that a given service provider may wish to work with more than one identity provider (e.g., commercial services with multiple customers, research resources used by researchers at multiple organizations). Likewise a given identity provider might wish to work with multiple service providers. When a group of service providers and identity providers agree to work together this group is usually called a federation.
一个Service Provider想要与多个Identity Provider交互并不是什么值得惊奇的事（就像一个商业服务对应多个客户，科研资料被多个学者和组织共用一样）。同样的，一个Identity Provider也可能会和多个Service Provider交互。当很多歌Service Provider和Identity Provider同意在一起工作的时候，我们就称它们为一个联盟。

Wrap Up
小结

So, that covers the basics of Single Sign-on systems and defines what we mean by "federation" and related terms. At this point you should review the previous steps again just to make sure you understand them before proceeding. Next we'll cover more advanced items that come up pretty quickly when using federated SSO systems: identity provider discovery, user attributes, and metadata. When you're sure you've got the basics down you can proceed to the next page.
以上涵盖了基本的SSO系统和联盟的定义以及相关概念。现在你需要做的是回顾一下上面的步骤，在使用它们之前确保你已经了解Shibboleth的工作方式。接下来我们要讨论一下联盟SSO使用的高级话题：如果你确定你已了解基本的SSO我们就可以开始下面的内容。