Cloud Design Pattern - Federated Identity Pattern(联合身份模式)

1.前言

传统应用通常都是多个模块运行在一个进程中,而随着云计算架构的不断演化,应用程序的各个模块以微服务的架构运行在多个进程中运行.最常见的就是ASP.NET WebApi,以WebApi构建的服务可以支持PC端,手机端,PAD端及其他任意形式的数据访问请求,那么api请求的认证如何来做呢?

ASP.NET 推出了基于OWIN的OAuth2认证与授权中间件,把认证与授权抽象成一个独立的服务,这样的服务可以成为一个独立的认证中心,对于第三方接入有很好的扩展性,非常有利于构建高扩展性的应用.这样的服务其实是可以管理多个应用的用户、角色、授权、认证的,也就是这里讲到的联合身份模式的实践.

关于ASP.NET中如何打造基于OWIN的OWIN OAuth2.0 Authorization Server,请参考:http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server

2.概念

在大中型企业中,通常有多个员工应用系统,如果每个系统都需要用户使用用户名和密码登录,用户很容易由于忘记密码,而无法登录系统,重置密码会造成较多的工作量.当员工离职的时候也需要逐一删除相关信息.每个系统都去维护人员,角色信息既会增加工作量,也会造成管理上的难度.

3.解决方案

正如在前言中所描述的那样,采用独立的用户认证与授权服务.

关于何时使用这种模式,官方说法如下:

This pattern is ideally suited for a range of scenarios, such as:

• Single sign on in the enterprise. In this scenario you need to authenticate employees for corporate applications that are hosted in the cloud outside the corporate security boundary, without requiring them to sign on every time they visit an application. The user experience is the same as when using on-premises applications where they are initially authenticated when signing on to a corporate network, and from then on have access to all relevant applications without needing to sign on again.
• Federated identity with multiple partners. In this scenario you need to authenticate both corporate employees and business partners who do not have accounts in the corporate directory. This is common in business-to-business (B2B) applications, applications that integrate with third party services, and where companies with disparate IT systems have merged or share resources.
• Federated identity in SaaS applications. In this scenario independent software vendors (ISVs) provide a ready to use service for multiple clients or tenants. Each tenant will want to authenticate using a suitable identity provider. For example, business users will want to us their corporate credentials, while consumers and clients of the tenant may want to use their social identity credentials.

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.
• 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.

4.示例

运行在云端的多租户应用中,我们就可以采用这种模式去完成租户与云端应用的用户,授权之间的映射.

5.相关阅读

关于这种模式的实现有很多种方式,相面的一些相关阅读可以帮助我们更好地了解这种模式.

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.