In many cloud scenarios, it's quite common that for the everyday business, your users need to work with different applications that comes from different providers and every application could have its own authentication mechanisms and credentials.

Imagine a business scenario where you have N different applications (on-premise applications, or cloud applications) and a user must have access to all of these N applications. In a standard environment, the user has to register in every application and remember every login accordingly.

As you can imagine, it could be quite difficult for an administrator to manage users and applications and users will have a better experience if they could use all these applications with the same credentials.

A solution for this scenario is to decouple authentication from authorization and (for authentication) using federated identity, where the user authentication must be delegated to a trusted identity provider.

The following picture shows a diagram of the Federated Identity Pattern:

With this pattern, when a client APPLICATION needs to authenticate on a cloud service, the cloud service forwards the authentication request to an IDENTITY PROVIDER. The IDENTITY PROVIDER checks the client identity and returns a Security Token with information about the authenticated user (identity plus additional information such as roles). The client can then use this token to once again authenticate the final application.

The flow of the steps involved in authentication is as follows:

1. The user requests access to the APPLICATION
2. The APPLICATION redirects the user to an IDENTITY PROVIDER
3. The user authenticates itself with the IDENTITY PROVIDER
4. The IDENTITY PROVIDER returns a Security Token to the user
5. The user returns to the application with the Security Token and the application allows access to the user accordingly with the permission granted by the Security Token

The IDENTITY PROVIDER can also be included into an Identity Management application that integrates external identity providers such as Azure Active Directory, ADFS, and Social Identity Providers. This is a quite common real-world scenario nowadays.

This pattern has many advantages, which are as follows:

• It supports SSO different applications by eliminating the need for multiple login credentials for every application
• Roles management is more easy and centralized
• No internal overhead of identity management for the cloud service (this task is provided by the IDENTITY PROVIDER)
• Authentication is decoupled from authorization—the Identity Provider is responsible for authentication, the application itself is responsible for the authorization
• More sophisticated authentication mechanisms (such as Two-Factor authentication, Multi-Factor authentication and so on) can be implemented in a central way (no need to implement them at the application level)
• You can grant access to your applications also to users that are external to your corporate

There's one big issue with this pattern—the IDENTITY PROVIDER could be a single point of failure. If it's not available, your applications will not work because no authentication will be provided. It's extremely important that the IDENTITY PROVIDER is an always up service, so it's better that this is managed by someone (like Microsoft) that can guarantee a high level of SLA.

With the Azure platform, you can implement federation on your cloud architecture using Active Directory Federation Services (AD FS). This provides a platform for having simplified, secured identity federation and single sign-on capabilities with cloud applications. A federation with Azure AD or Office 365 permits you to enable your users to use on-premise credentials in order to access all resources in the cloud.

Deploying AD FS in Azure permits you to have a centralized management of your network (via the Azure portal), permits you have scalability and high availability (by using Availability Sets), and also redundancy.