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我們就可以開始下面的内容。