Cloud computing Design Pattern (ix)--Federated identity mode

Cloud computing Design Pattern (ix)--Federated identity mode

Validates the delegate to the external identity provider. This model simplifies development, minimizes user management requirements, and improves the user experience of the application.

Background and issues

Users typically need to work with multiple applications that are provided and hosted by different organizations that have business relationships with them. However, these users may be forced to use specific (and different) vouchers for each one. This can be:
• A disjointed user experience. Users often forget to login credentials when they have a lot of different.
• Exposing security vulnerabilities. When the user leaves the company's account, the settings must be canceled immediately. It is very easy to overlook this in large organizations.
• Complex user management. Administrators must manage credentials for all users, as well as perform other tasks such as providing password hints.

Instead, users typically expect to use the same credentials for these apps.

Solution Solutions

Enables authentication mechanisms that can use federated identities. The separation of user authentication and authentication from application code to trusted identity providers can greatly simplify development and allow users to use a wider range of identity providers (IDPs) while minimizing administrative overhead for authentication. It also allows you to clearly separate the authorization certifications.

A trusted identity provider may include a corporate directory, an on-premises Federation Service, another security token service (STS's) business partner, or a social identity provider who can verify who owns the user, for example, Microsoft, Google, Yahoo or Facebook account.

Figure 1 illustrates the principle of federated identity mode when a client application needs to access a service that requires authentication. The authentication is performed by the identity provider (IDP) while singing its work with the security Token Service (STS). The issue of IDPs advocates information security tokens for authenticated users. This information is referred to as a claim, including the user's identity, and can also include additional information, such as role members and finer-grained access rights.

Figure 1-Federated authentication Overview


This model is often referred to as claims-based access control. Applications and services grant access to features and features that are based on claims that are included in tokens. Requirements for authentication must be trusted by the services of internally displaced persons. The contact of the client application performs the authentication of internally displaced persons. If the authentication is successful, the IDP returns a token that contains the claims used to identify the user to the STS (the IDP and STS can be the same service). In the STS can be changed and incremented in accordance with predefined rules, tokens in the claims book, before returning it to the client. The client application can then pass the token to the service as its proof of identity.

Note:

In some cases there may be additional trust chains for the Sts. For example, after the Microsoft Azure scenario Description, the on-premises STS Trust STS is another one that is responsible for the access of the identity provider to authenticate the user. This approach is common in enterprise situations, where there is a local STS and directory.



Federated authentication provides a standard-based solution for the issue of identity in different trusting domains, and can support single sign-on. It is becoming more and more common in all types of applications, especially cloud-hosted applications, because it supports the single sign-on without the need for direct network connectivity to identity. Users do not have to enter credentials for each application. This adds security because it prevents the proliferation of credentials required to access many different applications, while also hiding the credentials of the user all but the original identity provider. The application sees only the authentication information contained in the token.

Federated identity also has a significant advantage, that is, the identity and credential management is the responsibility of the identity provider. An application or service does not need to provide identity management functionality. Also, in an enterprise environment, the enterprise directory does not need to know about the user (who provides the identity provider it trusts), and it removes all administrative overhead of managing the identities of users in that directory.

Issues and considerations

Consider the following factors when designing an application that implements federated authentication:
• Authentication can be a single point of failure. If you deploy applications to multiple datacenters, consider deploying identity management mechanisms to the same data center to maintain application reliability and availability.
• Authentication mechanisms that can provide tools to configure access control based on claims that are included in the authentication token's role. This is often referred to as role-based access control (RBAC), and it can allow control to access more granular levels of functionality and resources.
• With the corporate directory, the use of social identity providers typically does not provide an email address other than the user for authentication, perhaps the name information is based on the claims identity. Some social identity providers, such as Microsoft accounts, provide only a unique identifier. An application will typically need to maintain some information about the registered user and be able to match that information with the identifiers of the claims contained in the token. Typically, this is the first time a user accesses the application through a registration process, and the information is then injected into the token as a claim appended to each authentication.
• If configured as an STS for multiple identity providers, it must detect its identity provider and the user should be redirected to authentication. This process is known as the main domain discovery. The STS may be able to automatically execute this browser based on the email address or user name that the user provides, the user's IP address range, the application's domain, or the user's content stored on the cookie. For example, if a user enters an email address in a Microsoft domain, such as [email protected] , the STS redirects the user to the Microsoft Account sign-in page. In subsequent visits, the STS can use cookies to represent the last logged-on Microsoft account. If Autodiscover cannot determine the primary realm, the STS displays a home domain Discovery (HRD) page that lists the trusted identity providers that the user must select who they want to use.

when to use this mode

This pattern is well suited for situations in the range, such as:
• Single Sign-on at the enterprise. In this case, you need to verify that the employee is hosted in an enterprise application other than the enterprise security boundary in the cloud, without requiring them to sign each time they access the application. The user experience is the same as the use of local applications, when they are contracted to the corporate network, when they initially authenticate, and then get all the relevant applications, without having to sign in again.
• Federated identities with multiple partners. In this case, you need to verify that the two enterprise employees and business partners who are not in the company directory account. This is an enterprise-to-business application that integrates with third-party services, and where it merges or shares resources with different IT systems companies in general.
• Federated identities in SaaS applications. In this scenario, an independent software vendor (ISV) provides a ready-to-use service for multiple customers or tenants. Each tenant will be authenticated using the appropriate identity provider. For example, enterprise users would want our own corporate credentials, and tenants and customers might want to use their own social credentials.

This mode may not be suitable for the following situations:
• All users of the application can authenticate through an identity provider and do not require any other identity provider to authenticate. This is typically a business application that uses only the enterprise directory for authentication, and obtains the directory to use the VPN directly in the application, or (in the case of hosting in the cloud), connect the local directory and the application by connecting the virtual network between.
• The application is initially built with the ability to use different authentication mechanisms, perhaps with custom user storage, or without the negotiation criteria for processing the claims-based technology used. Transforming claims-based authentication and access control to existing applications can be complex and may not be cost-effective.

Example

The organization hosts multi-tenant software, which is a service (SaaS) application in Azure. The application incudes a Web site that tenants can use to manage applications for their own users. The application allows tenants to access the tenant's Web site using federated identities generated by the Active Directory Federation Service (ADFS) when the user is authenticated through the organization's own active directories. Figure 2 shows an overview of the process.

Figure 2-How users access applications in large enterprise users


In the scenario shown in Figure 2, the merchant validates its identity provider (step 1), in this case ADFS. In the successful authentication of the tenant, ADFS issued the token. The client browser forwards this token to the federated provider of the SaaS app, whose trusted tenant's ADFS issues the token so that the retrieved token is a valid SaaS syndication provider (step 2). If necessary, the claims in the claims in the SaaS consortium provider are executed to the transform that the application recognizes before the new token is returned to the client browser (step 3). The application trusts the token issued by the Federation provider of the SaaS and uses the claims in the token to request authorization rules (step 4).

Tenants will no longer need to remember different credentials to access the application, and the administrator tenant's company will be able to configure a list of users who can access the application in their ADFS configuration.

This article is translated from msdn:http://msdn.microsoft.com/en-us/library/dn589790.aspx

Cloud computing Design Pattern (ix)--Federated identity mode