Welcome!

Web 2.0 Authors: Roger Strukhoff

Related Topics: Cloud Expo, SOA & WOA, .NET, Virtualization, Security, Big Data Journal

Cloud Expo: Article

Identity Challenges in Cloud Computing

Identity scenarios and solutions using Windows Azure

Enterprises are seeing a great potential in cloud-based services. However, security is a primary concern that keeps enterprise from harnessing the full potential. Identity management is one of the most important aspects of security. There is always an authentication required in an application to identify the user and provide service based on the user details. Authorization is required to allow only privilege user to execute privilege operation. An identity store required to maintain the identity and roles for the user.

Identity Management is a solution that takes into consideration all the identity concerns: authentication, authorization and maintaining identity.

In this article we will discuss some of the challenges occur while moving to the cloud in terms of identity. And what are the Microsoft technologies available to resolve identity management issues over the cloud and scenarios and solutions to use those technologies

Challenges on Identity Management While Moving to Cloud
Maintaining Identity for on-premise applications is easy, as you can have a centralized source of Identity which can be used across all applications since they are hosted in your own private network.

Challenges emerge when attempting migration to cloud or building a new application for cloud where the applications would not have direct access to the on-premise directory. Some of the challenges are:

  • Most of the origination will already have their own directory setup in their premises and as for security it will be good to maintain it at centralized location at the premise itself. So organization tents to reuse the same over the cloud also.
  • To access corporate application user should not has to setup a VPN connection to their network, application should be allowed to access over the internet
  • Multiple applications which are tightly coupled with the on-premise identity store like Sql server and the customer want to keep the identity and central location do not want to span to multiple store.
  • Allowing user to log once and access all the application seamlessly by adding the single sign-on capability.

To make application extensible such a way without much modification it should work with multiple identity providers which follows different protocols.

Let's look in the following section how Windows Azure platform give solutions to this issues.

Different technique of Identity management
Identity management structure can be classified in two major groups, Role based and Claim based access.

Role-based access
Roles based access is a traditional approach out of most authorization process. In role based authentication user provides credential such as username and password to application, and user will be authenticated based on that. User will map to groups or roles and permissions are provided based on the group or role. Application store user details along with credential in an identity store.

Some of the generally used Microsoft Technologies to implement Role based Identity for on-premise and over the Azure -

ASP.net Membership Profile - This is simple yet powerful technique, where identity can be store on SQL Server or SQL Azure.

Windows Identity - The on premise application can be authenticated directly by windows directory such as Active Directory. Whereas when moving to Azure, domain join could be created by Azure Connect between on-premise and Azure Cloud service, to access on premise windows directory.

Custom store- Custom Identity store can be created over SQL Server or SQL Azure.

Claim-based access
In a Claim-based approach the user provides credentials to Identity Provider's Secure Token Service (IP STS), IP STS in turn provides the signed token which has collection of claims, Application extract the claims from token and use the information to execute the business process. Figure shows a simple picture of how this happens.

Trust need to be created between IP STS and Application (Relying Party) by setting up the different protocols, policies and rules for generating a token. Application only accepts the token from the issuer (STS) which it trusts.

Difficulty arise, what if user want to get authenticated by the Identity Provider which Application doesn't trust.  We can take one step further to claim based by going to identity federation.

Federation
In Federation, the issuer can accept the token form another issuer, instead of authenticating user directly.  So issuer becomes federation provider (FP- STS) not only issue token as well accept token from the other Identity Provider (IP- STS). The figure below shows how identity federation is used.

Users first authenticate with an IP- STS and get the Token. They present the tokens they receive from IP -STS to FP-STS, which accepts it and authenticating them directly and Issue token for application to use. This token is what the user sends to application.

Getting security token form STS can be done actively or passively.  Active Federation where Relying Party should own login logic where as in passive from browser user gets redirected to the login page hosted by STS. Typically Active Federation uses when Authentication needs to build on Service rather than UI part, where as Passive Federation use to provide authentications of users accessing a web site.

Microsoft Technologies to implement Claim-based Federated Identity for on-premise and over Azure:

  • Windows Identity Foundation (WIF): WIF is a set of .NET Framework classes that implement essential identity functions, such as receiving a token, verifying its signature, and accessing the claims it contains.
  • Windows Active Directory Service2.0: Its fully featured STS built on Active Directory. The same AD FS 2.0 instance can act as either an identity provider STS or a federation provider STS.
  • Windows Azure Access Control Service (ACS): ACS works as a Cloud-based federation provider STS. it simplify user access and authorization in application. ACS allowed application running on cloud or on premise to access the token form on-primes STS of different organization as well as access the token form different cloud identity providers like Windows Live ID, Google, Facebook, Yahoo, and OpenID. ACS supports various protocols, including WS-Federation, WS-Trust, OpenID 2.0, and OAuth 2.0. and accept and issue tokens in  SAML and Simple Web Token (SWT) formats.
  • Windows Azure Active Directory (WAAD): WAAD is a cloud extension of Windows Server AD. It offers users to extended already existing on-premises Active Directory to the cloud and provides a highly scalable enterprise identity management solution. WAAD is underlying technology for identity management in Office 365, Dynamics CRM Online, Windows Intune, and Windows Azure Online Backup. So if customer has Office 365 / Windows Intune Online accounts, He is already a WAAD-Tenant. There are two major scenarios where WAAD can be used for application building for a single organization or provides support for multi tenant software-as-a-service (SaaS) applications.

Scenarios and Solutions for identity management in Azure
Let's take a very basic scenario where organization migrate an application to azure which use windows authentication to grant access to its user.

Domain join can be created by using Azure connect between Hosted Azure VM / web role to the on-premise network. With this approach there are no changes required in the access management of the application. User can login to the application with their windows credentials as it is allowed in on premise application.

Let's take a another scenario two trading partners exchanging purchase-order messages, where a large high-tech equipment manufacturer to migrate there web application to Azure which use for partners exchanging purchase-order message. Where application should allowed organization and partner user to access the application with their domain credentials

One of the solutions could be federating authentication with Azure ACS.  Where between organization and partner Issuer trust can be created with ACS. And the application needs to configure for accepting the token form ACS.

As diagram depict if organization user logs in; user will get redirected to organization ADFS server to get authenticated; whereas for partner user, user get authenticated by their STS.

To make user more convenience automated home realm discovery (HRD) can be implemented where based on cookies or URI/ query string user directed to direct their organization ADFS server.

Benefits of the solution are any number of partners can be connected to site by just doing a configuration in ACS. Or same site can be accessed by the any other social identity providers. As the overhead of the understanding the token format and protocol used by Identity providers is done by the ACS, so no much changes required at application site with respect to identity management.

As the growing the use of the smart phone; user wants their most of the work done by the smart phone itself. User expects to gain access to his data and service same as he gets on his PC. Let's take a scenario where a windows phone app needs to give an access to user with their existing identity and the same time they have to expose secure service that integrate with multiple web identity provider.

Internal web service hosted on premise could be exposed to internet by a secured Azure service bus; same can be consumed by the windows phone application.

To secure the service bus there could be two ways one by Shared Secret or by ACS, In ACS we can configured for the different web identity providers based on the requirement.

Here the windows phone application can authenticate by using passive federation model with ACS. ACS will redirect the user to selected identity provider Login page user will get authenticated by the IP and ACS will generate the SWT / SAML token based on the Token provided by the IP. As in passive federation, we should verify that issuer renders a suitable sign-in page.

Let's take another example where an independent software vendor (ISV), is building a customer relationship management (CRM) solution as a SaaS (Software as a service) based Application. Where for each new customer application need to give access to customer user based on their domain credential. Using Windows Azure AD it's easy to develop identity management for a SaaS based application where application can be easily integrated with multiple WAAD Tenants. Once application is integrated with one WAAD account, there will be no much change to integrate another.

Application should maintain the Windows Azure AD tenants info and key for checking signatures on tokens coming from Windows Azure AD with the respective customer. On first login of the Customer admin it should redirect to a consent page, where he can configure application to access their Windows Azure directory.

Add some logic to redirect unauthenticated requests to the correct Windows Azure AD tenant for user authentication. And the users who authenticated with Windows Azure AD can be recognized and granted access.

Summary
Azure support both Role-based and Claim-based access management approach. Domain join can be used to achieve windows authentication on azure similar to on-primes. SQL Azure can used to store member ship profile data for role based authentication. For claim based access ACS and WAAD can used in Azure.

ACS could be used for securing Service Bus, web service and web application. Windows Azure Active Directory enables solutions for many common scenarios such as single sign-on, authentication for multitenant application.

References

More Stories By Priyamvada Nigam

Priyamvada Nigam works as a Technical Analyst at Tech Mahindra. She is interested in Microsoft technologies such as ASP.net, WCF, WWF, and Azure. For the past three years she has been working on Azure technologies.