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 user@live.com, 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.