宣告式身分識別模型
如果您建立宣告感知 (Claims-Aware) 應用程式，使用者會以一組宣告的方式來向應用程式提交身分識別。 其中一個宣告可能是使用者的名稱，另一個可能是電子郵件地址。 本節要說明的，就是外部身分識別系統已設定成向您的應用程式提供它在每次發出要求時必須讓應用程式知道的使用者相關資料，以及您從信任來源接收之身分識別資料的加密保證。
在這個模型下，單一登入變得更容易進行，而且您的應用程式不再需要負責下列工作：
驗證使用者。
儲存使用者帳戶和密碼。
呼叫企業目錄來查詢使用者身分識別詳細資料。
整合至其他平台或公司的身分識別系統。
在這種模型下，您的應用程式可以根據使用者提供的宣告來做出與身分識別相關的決策。 無論是以使用者的名字進行簡單的應用程式個人化，或是授權使用者存取應用程式中更高級的功能和資源，都屬於這類決策的範圍。
不只是同盟
最初在宣告式身分識別模型背後的設計用意，在於啟用組織之間的同盟功能，但隨著時間變遷，宣告的提供不再僅限於為了達成同盟。 然而其中一些名詞仍然保留原意。 例如，當您在 ASP.NET 應用程式中使用 WIF 時，您必須使用稱為 WSFederationAuthenticationModule 的 WIF 元件，才能執行宣告處理。 請勿混淆「同盟」(Federated) 的意思。 建立委外驗證和授權的應用程式有許多好處。 任何已經具有或打算在未來建立 Web 應用程式或 Web 服務的公司，都可以從開始建立宣告式身分識別模型獲益。
宣告式身分識別簡介
本節主題將介紹相關詞彙和概念，以協助您了解這個新的身分識別架構。
身分識別
「身分識別」(Identity) 是經常讓人發生混淆的詞彙。 比方說，在這個主題中是用這個詞彙來描述驗證和授權。 但是若是要描述在 WIF 中的程式設計模型，我們就會用「身分識別」一詞來描述一組屬性，而這些屬性可描述系統中您要保護的某位使用者或某個其他實體。
宣告
請將宣告想成像是姓名、電子郵件地址、年齡、銷售角色中的成員資格等身分資訊中的一部分。 應用程式接收到的宣告越多，您就可以越清楚您的使用者。 您可能會想為什麼這類資訊要稱為「宣告」，而不是稱為多半在描述企業目錄時所使用的「屬性」(Attribute)。 原因出在傳遞方法。 使用這種模型時，您的應用程式不會查詢目錄中的使用者屬性 (Attribute)。 而是由使用者將宣告傳遞給應用程式，接著由應用程式檢查這些宣告。 每一個宣告都是由簽發者所提出，因此您會根據信任該簽發者的情形來決定是否信任該宣告。 例如，相對於使用者提出的宣告，您會比較信任由自家公司網域控制站所提出的宣告。 WIF 代表類型為 Claim 的宣告，這類宣告具備的 Issuer 屬性 (Property) 可用來找出簽發該宣告的簽發者。
安全性權杖
使用者會將一組宣告連同要求一起傳遞給您的應用程式。 在 Web 服務中，這些宣告會在 SOAP 封套的安全性標頭中運送。 在瀏覽器型的 Web 應用程式中，宣告則會從使用者瀏覽器透過 HTTP POST 送達，而且稍後如果需要工作階段的話，可以儲存在 Cookie 中進行快取。 無論這些宣告是用哪種方式送達，它們一定會經過序列化，而這就是安全性權杖的傳入管道。安全性權杖就是由發行授權單位用數位方式簽署的一組序列化宣告。 簽章很重要：它可以向您保證使用者不只是準備了一堆宣告，還將這堆宣告傳送給您。 您可以在不一定需要或是不需要加密的低安全性狀況中使用未簽署的權杖，不過這類案例不在本主題討論範圍。
WIF 的核心功能之一是建立和讀取安全性權杖。WIF 和 .NET Framework 會處理所有的加密工作，並向您的應用程式提交您可以讀取的一組宣告。
發行授權單位
發行授權單位分為許多類型，從簽發 Kerberos 票證的網域控制站到發行 X.509 憑證的憑證授權單位都是，不過在本主題中所討論的特定授權單位類型會簽發包含宣告的安全性權杖。 這種發行授權單位是清楚如何簽發安全性權杖的 Web 應用程式或 Web 服務。 它必須徹底清楚如何在目標信賴憑證者和使用者發出要求時簽發適當的宣告，而且可能要負責與使用者存放區互動，以便查詢宣告和驗證使用者本身。
無論您選擇使用哪一種發行授權單位，它都是身分識別解決方案中的核心角色。 當您信賴宣告方式而在應用程式之外進行驗證，表示您已將責任轉交給該授權單位，並要求它代表您來驗證使用者。
標準
為了讓上述提到的每個部分都可交互操作，上述案例會使用幾項 WS-* 標準。 使用 WS-MetadataExchange 來擷取原則，而原則本身的結構則以 WS-Policy 規格為基礎。 STS 會公開實作該 WS-Trust 規格的端點，此規格會描述如何要求和接收安全性權杖。 今日大多數 STS 會簽發採用安全性聲明標記語言 (SAML) 格式的權杖。 SAML 是業界普遍認可的 XML 詞彙，可在交互操作方式中用來出示宣告。 此外，在多平台狀況下，這個方式可讓您與位在完全不同平台上的 STS 進行通訊，針對您的所有應用程式進行單一登入，而不管平台為何。
瀏覽器型的應用程式
智慧型用戶端並非可使用宣告式身分識別模型的唯一應用程式。 瀏覽器型的應用程式 (亦稱為被動用戶端) 也可以使用這個模型。 下面案例會說明其運作方式。
首先，使用者將瀏覽器指向宣告感知 Web 應用程式 (即信賴憑證者應用程式)。 Web 應用程式將瀏覽器重新導向到 STS，如此該使用者便可進行驗證。 STS 裝載於一個簡單 Web 應用程式上，該應用程式可讀取傳入要求，使用標準 HTTP 機制驗證使用者，然後建立 SAML 權杖並回覆一段 JavaScript 程式碼，該段程式碼可使瀏覽器啟動將 SAML 權杖傳回 RP 的 HTTP POST。 這個 POST 的主體包含 RP 所要求的宣告。 這時通常 RP 會將宣告封裝到 Cookie 中，如此就不需要針對每次要求而令使用者重新導向。
資訊卡和識別選取器
WIF 會提供資訊卡序列化所適用的 API，其可在應用程式中用來建立 Managed 資訊卡發佈以及啟用資訊卡登入。 如需 ，請參閱使用 CardSpace。
識別選取器提供下列功能：
協助使用者管理 Web 的多個身分識別。
協助使用者為指定的信賴憑證者選取適當的身分識別。
協助保護使用者的隱私。