Federated Identity Pattern 聯合身份模式

Delegate authentication to an external identity provider. This pattern can simplify development, minimize the requirement for user administration, and improve the user experience of the application.

向外部身份提供程序的委托身份驗證。這種模式可以簡化開發，最大限度地減少對用戶管理的要求，提高了應用程序的用戶體驗。

Context and Problem 情景和問題

Users typically need to work with multiple applications provided by, and hosted by different organizations with which they have a business relationship. However, these users may be forced to use specific (and different) credentials for each one. This can:

用戶通常需要工作與多個應用程序提供的，並由不同的組織，他們有一個業務關系。然而，這些用戶可能被迫使用特定的（和不同的）憑據。這可以：

• Cause a disjointed user experience. Users often forget sign-in credentials when they have many different ones.
• 造成脫節的用戶體驗。用戶經常忘記登錄憑據，當他們有許多不同的憑證時。
• Expose security vulnerabilities. When a user leaves the company the account must immediately be deprovisioned. It is easy to overlook this in large organizations.
• 暴露安全漏洞。當用戶離開公司帳戶必須立即deprovisioned。在大型組織中很容易忽視這一。
• Complicate user management. Administrators must manage credentials for all of the users, and perform additional tasks such as providing password reminders.
• 復雜用戶管理。管理員必須管理所有用戶的憑據，並執行額外的任務，如提供密碼提醒。

Users will, instead, typically expect to use the same credentials for these applications.

用戶非常願意而不是通常期望使用相同的憑據來使用這些應用程序。

Solution 解決方案

Implement an authentication mechanism that can use federated identity. Separating user authentication from the application code, and delegating authentication to a trusted identity provider, can considerably simplify development and allow users to authenticate using a wider range of identity providers (IdPs) while minimizing the administrative overhead. It also allows you to clearly decouple authentication from authorization.

實現可以使用聯合標識的身份驗證機制。從應用程序代碼分離的用戶認證和授權認證，可信身份提供商，可以大大簡化開發，允許用戶進行身份驗證，使用范圍更廣泛的身份提供者（IDP）同時最大限度地減少管理費用。它還允許您從授權中清楚地分離身份驗證。

The trusted identity providers may include corporate directories, on-premises federation services, other security token services (STSs) provided by business partners, or social identity providers that can authenticate users who have, for example, a Microsoft, Google, Yahoo!, or Facebook account.

可信身份提供者可能包括企業目錄，處所聯合服務，其它的安全令牌服務（STS）的商業合作伙伴提供，或社會身份提供商，可以驗證用戶的身份的人，例如，微軟，谷歌，雅虎！或臉譜網帳戶。

Figure 1 illustrates the principles of the federated identity pattern when a client application needs to access a service that requires authentication. The authentication is performed by an identity provider (IdP), which works in concert with a security token service (STS). The IdP issues security tokens that assert information about the authenticated user. This information, referred to as claims, includes the user’s identity, and may also include other information such as role membership and more granular access rights.

圖1說明了當客戶端應用程序需要訪問需要身份驗證的服務時，聯合身份模式的原則。認證是由身份提供商進行（IDP），工作在一個安全令牌服務（STS）音樂會。國內流離失所者問題的安全令牌的身份驗證的用戶信息維護。這些信息，被稱為索賠，包括用戶的身份，並可能還包括其他信息，如角色成員和更多的細微的訪問權。

Figure 1 - An overview of federated authentication 圖1 -聯合身份驗證的概述

This model is often referred to as claims-based access control. Applications and services authorize access to features and functionality based on the claims contained in the token. The service that requires authentication must trust the IdP. The client application contacts the IdP that performs the authentication. If the authentication is successful, the IdP returns a token containing the claims that identify the user to the STS (note that the IdP and STS may be the same service). The STS can transform and augment the claims in the token based on predefined rules, before returning it to the client. The client application can then pass this token to the service as proof of its identity.

這個模型通常被稱為基於訪問控制要求。應用程序和服務授權訪問基於令牌中包含的聲明的功能和功能。服務需要認證必須信任IDP。客戶端應用程序聯系IDP執行身份驗證。如果認證成功，IDP返回令牌包含識別用戶的STS的要求（注意，IDP和STS可以相同的服務）。STS可以變換和增加基於預定義的規則的令牌請求，然后返回到客戶端。客戶端應用程序可以將此令牌傳遞給服務作為其身份的證明。

Note:注：

In some scenarios there may be additional STSs in the chain of trust. For example, in the Microsoft Azure scenario described later, an on-premises STS trusts another STS that is responsible for accessing an identity provider to authenticate the user. This approach is common in enterprise scenarios where there is an on-premises STS and directory.

在某些情況下有可能在信任鏈附加的STS。例如，在微軟的Azure場景描述后，對房產信托的另一個STS STS，負責訪問身份提供商對用戶身份進行驗證。這種方法在企業的情況下，有一個處所STS和目錄是常見的。

Federated authentication provides a standards-based solution to the issue of trusting identities across diverse domains, and can support single sign on. It is becoming more common across all types of applications, especially cloud-hosted applications, because it supports single sign on without requiring a direct network connection to identity providers. The user does not have to enter credentials for every application. This increases security because it prevents the proliferation of credentials required to access many different applications, and it also hides the user’s credentials from all but the original identity provider. Applications see just the authenticated identity information contained within the token.

聯合認證提供了一個基於標准的解決方案的問題，在不同的領域的信任的身份，並可以支持單點登錄。它正變得越來越常見，在所有類型的應用程序，特別是雲托管應用程序，因為它支持單點登錄，而不需要直接的網絡連接到身份提供商。用戶不必為每一個應用程序輸入憑據。這增加了安全性，因為它防止訪問許多不同的應用程序所需的憑據的增殖，它也隱藏了用戶的憑據，從所有，但原來的身份提供者。應用程序只看到包含在令牌中的身份驗證的身份信息。

Federated identity also has the major advantage that management of the identity and credentials is the responsibility of the identity provider. The application or service does not need to provide identity management features. In addition, in corporate scenarios, the corporate directory does not need to know about the user (providing it trusts the identity provider), which removes all the administrative overhead of managing the user identity within the directory.

聯合身份也有管理的身份和憑據的主要優點是身份提供者的責任。應用程序或服務不需要提供身份管理功能。此外，在企業場景中，企業目錄不需要知道用戶（提供它信任的身份提供程序），它刪除了目錄中管理用戶身份的所有管理開銷。

Issues and Considerations 問題與思考

Consider the following when designing applications that implement federated authentication:

• Authentication can be a single point of failure. If you deploy your application to multiple datacenters, consider deploying your identity management mechanism to the same datacenters in order to maintain application reliability and availability.
• 認證可以是一個單一的故障點。如果你部署到多個數據中心的應用程序，考慮部署你的身份管理機制，同一數據中心為了保持應用程序的可靠性和可用性。
• Authentication mechanisms may provide facilities to configure access control based on role claims contained in the authentication token. This is often referred to as role-based access control (RBAC), and it may allow a more granular level of control over access to features and resources.
• 認證的機制可能為它配置訪問控制和基於角色的認證令牌類型的物理位置。這是一個通常稱為角色為基礎的存取控制（rbac），它可以允許更多的控制和granular水平的特點和資源的訪問。
• Unlike a corporate directory, claims-based authentication using social identity providers does not usually provide information about the authenticated user other than an email address, and perhaps a name. Some social identity providers, such as a Microsoft account, provide only a unique identifier. The application will usually need to maintain some information on registered users, and be able to match this information to the identifier contained in the claims in the token. Typically this is done through a registration process when the user first accesses the application, and information is then injected into the token as additional claims after each authentication.
• 與企業目錄不同，使用物理為基礎的社會身份認證提供者並不提供關於用戶的信息authenticated經常比其他的電子郵件地址，或一個名稱。一些社會身份提供者，如微軟的客戶，提供獨特的，唯一的標識符。它的應用將需要一些信息，他經常保持注冊的用戶，和能匹配標識符包含此信息的物理令牌。通常這是不通過的注冊過程中，當用戶第一accesses的應用和信息中心，然后injected作為額外的物理令牌的認證后的選擇。
• If there is more than one identity provider configured for the STS, it must detect which identity provider the user should be redirected to for authentication. This process is referred to as home realm discovery. The STS may be able to do this automatically based on an email address or user name that the user provides, a subdomain of the application that the user is accessing, the user’s IP address scope, or on the contents of a cookie stored in the user’s browser. For example, if the user entered an email address in the Microsoft domain, such as [e-mail], the STS will redirect the user to the Microsoft account sign-in page. On subsequent visits, the STS could use a cookie to indicate that the last sign in was with a Microsoft account. If automatic discovery cannot determine the home realm, the STS will display a home realm discovery (HRD) page that lists the trusted identity providers, and the user must select the one they want to use.

This pattern might not be suitable in the following situations:這家現代化的模式不可能在以下問題：

• All users of the application can be authenticated by one identity provider, and there is no requirement to authenticate using any other identity provider. This is typical in business applications that use only a corporate directory for authentication, and access to this directory is available in the application directly, by using a VPN, or (in a cloud-hosted scenario) through a virtual network connection between the on-premises directory and the application.
• 應用程序的所有用戶是可以被認證的通過身份提供商，不在需要使用任何其他提供商的身份。這是一個典型的應用程序使用，只有在企業和公司的認證和訪問的目錄，這個目錄的應用程序是可用的，並通過使用VPN，或（在雲- hosted scenario）和虛擬網絡之間的連接，通過在線目錄和明確的應用。
• The application was originally built using a different authentication mechanism, perhaps with custom user stores, or does not have the capability to handle the negotiation standards used by claims-based technologies. Retrofitting claims-based authentication and access control into existing applications can be complex, and may not be cost effective.

Example 例子

An organization hosts a multi-tenant Software as a Service (SaaS) application in Azure. The application incudes a website that tenants can use to manage the application for their own users. The application allows tenants to access the tenant’s website by using a federated identity that is generated by Active Directory Federation Services (ADFS) when a user is authenticated by that organization’s own Active Directory. Figure 2 shows an overview of this process.

一個組織的主機和多承租人的軟件作為服務（SaaS）應用在Azure。應用包括占有者網站，可以使用它管理應用程序自己的用戶。應用的占有者可以訪問的網站通過使用聯合身份認證和federated的融合活性的目錄服務（adfs聯合會），當一個用戶是authenticated組織活性，與自己的目錄。介紹了一個數字2的分析過程。

Figure 2 - How users at a large enterprise subscriber access the application 圖2大型企業用戶如何訪問應用

In the scenario shown in Figure 2, tenants authenticate with their own identity provider (step 1), in this case ADFS. After successfully authenticating a tenant, ADFS issues a token. The client browser forwards this token to the SaaS application’s federation provider, which trusts tokens issued by the tenant’s ADFS, in order to get back a token that is valid for the SaaS federation provider (step 2). If necessary, the SaaS federation provider performs a transformation on the claims in the token into claims that the application recognizes (step 3) before returning the new token to the client browser. The application trusts tokens issued by the SaaS federation provider and uses the claims in the token to apply authorization rules (step 4).

Tenants will not need to remember separate credentials to access the application, and an administrator at the tenant’s company will be able to configure in its own ADFS the list of users that can access the application.

Tenants不必記住訪問應用程序的隔開憑證，在Tenant公司的管理員會配置自己的ADFS用戶列表以便訪問應用程序。

Related Patterns and Guidance相關的模式和指導

At this time, there are no related patterns and guidance.

沒有相關模式和相關的指導。

More Information 更新信息

For more information on the federated authentication technologies you can use in Azure applications, see the following:

• Microsoft Azure Active Directory on the Azure website.
• Active Directory Domain Services on MSDN.
• Active Directory Federation Services on MSDN.
• Windows Identity Foundation on MSDN.
• Developing Multi-Tenant Web Applications with Microsoft Azure AD on MSDN.

For comprehensive information about claims-based identity and federated authentication see:

• Federated Identity: Scenarios, Architecture, and Implementation on MSDN.
• Federated Identity Patterns in a Service-Oriented World in the Architecture Journal.