Windows Azure: Authenticate Windows Azure with ADFS
The demand for anytime and anywhere access to corporate data requires multiple levels of remote authentication.
Dan Griffin and Tom Jones
Savvy executives are using mobile and cloud computing as a strategic asset to increase the speed and flexibility of their decision-making processes. Mobile devices have already proven their value in business. Users have anywhere, anytime access to the data they need in order to remain productive.
The proliferation of smartphones and tablet computers—not to mention the demand for cloud computing—has increased the pressure on IT departments to provide secure mobile access to valuable enterprise content. In short, if you aren’t investing in formal IT support for secure mobile computing, you can be sure your competitors are. They will make it a differentiator.
Any internal investment in mobile computing must account for data security. You must also plan for the potential cost in user satisfaction that security hurdles can incur. For example, there has long been a desire for a unified mechanism by which to securely authenticate both on-premises and remote users. This includes handheld devices, desktop devices, and new and legacy applications.
Flexible and cost-effective identity-management solutions have been hard to find. Users get annoyed at requests for yet another logon credential. Furthermore, when the user has the same logon credential stored at multiple sites, the risk of identity theft or accidental disclosure increases.
The good news for IT is that mobile computing is a clear example of IT security as a business enabler. Plus, the latest authentication and authorization technologies can make true security seamless for the user.
At the 2013 RSA Conference, the United States National Security Agency’s mobility mission manager explained why even the most security-sensitive environments require cohesive support for the road warrior. IT departments need to enable services and devices that support a variety of user-authentication mechanisms.
You can adapt an existing identity-management solution such as Microsoft Active Directory Federation Services (AD FS) to a typical line-of-business (LOB) Web application running in the Windows Azure cloud environment. You can also readily apply the general form of the solution described here to other identity-management solutions, applications and cloud services.
Existing authentication methods
Within the Windows framework, Directory Services has always been the traditional repository for enterprise user identities. This is designed to give employees access to network assets behind a firewall where Kerberos is the dominate protocol.
Because Kerberos isn’t recommended for use on the Internet, most organizations use Web-based authentication protocols such as Security Assertion Markup Language (SAML), Simple Web Token (SWT) and JSON Web Token (JWT). These newer Web tokens are not yet accommodated by most enterprise directory services, so you’ll need an additional service—called the Security Token Server (STS)—to connect the traditional directory to the latest Web applications.
Separating roles is important. Each LOB application server shouldn’t also be responsible for user authentication. What the application server needs is the ability to rely on some other service to do the heavy lifting of providing identity and authorization information in a flexible way. This is what’s generally referred to as “federated identity.”
Federation means that the application server (the relying party, or RP) establishes a trust relationship with the identity provider. It must understand how to evaluate the user identity metadata provided in the form of claims.
For example, imagine a user trying to access content on a network service (see Figure 1). The RP requests a collection of claims routed by an application (for example, the Web browser) on the user device to one or more STSes. The user authenticates to the STS with whatever credential has been provided: password, smart card and so on. The only direct connection between the RP and the STS is the initial configuration wherein trust is established between the two (typically, you’d configure each with the server certificate of the other).
.jpg "When a user requests secure content, that request kicks off a series of cross-checks.")
Figure 1 When a user requests secure content, that request kicks off a series of cross-checks.
AD FS and Windows Azure in the real world
One option is to configure AD FS as the STS. AD FS shields the internal Active Directory Domain Services (AD DS) from external attack by accepting requests for authentication from the Internet. AD FS translates the Active Directory-based identity into an Internet-friendly format.
The external device in this case is a Windows tablet. The device is communicating on an external network connection to a Web application server (the RP) hosted in the Windows Azure cloud. The application server needs to know the user authenticated by AD FS is using a computer that’s compliant with network policies.
As security expert Butler Lampson has said for years, “All trust is local.” In other words, the RP needs to be able to perform its own claims validation before it can authorize access to application content. That validation and authorization is based on the user identity and device compliancy claims issued by an STS. The user’s device then drives that authentication data exchange (see Figure 2).
.jpg "It takes a series of claim responses to validate a data request.")
Figure 2 It takes a series of claim responses to validate a data request.
An agent on the device collects claims from a variety of sources and combines them into a response to the application server. That response must meet all criteria to enable access to the protected data. User-identity claims and device-health-compliancy claims may come from different STSes, as depicted in Figure 2, or from a single STS with multiple sources of claims metadata (for example, Active Directory plus Microsoft System Center Configuration Manager).
You can alter the blend of identity and attribute providers to meet the needs of the RP Web service. For example, you could combine Office 365 authentication with client device measurements to meet data-loss-prevention policies. In all cases, the RP request will go to a user agent in the user device. That will marshal the claims from several sources to meet the RP’s demands.
Many Web authentication scenarios let the user device cache claims for later use. This is often called a “Keep Me Signed In” scenario. The RP even has the option to request additional claims from the user as needed by the transaction requested by the user. This is known as “step up” authorization.
AD FS and identity support
For Windows-based LOB application developers, federation support is built into the Microsoft .NET Framework 4.5. Developers don’t need to become security experts in order to enable the scenarios described here.
While the .NET Framework 4.5 doesn’t ship with SWT and JWT support, adding these structures is well-documented. Microsoft has released a JWT handler for the .NET Framework 4.5. Windows Server 2012 comes with AD FS 2.1 as an integrated server role that now supports the .NET Framework 4 application pools. You’ll need this to support the JWT handler and other advanced features.
Claims-based access control is useful when partnering across enterprise boundaries because it separates authentication (for example, to on-premises Active Directory) from authorization (for example, to shared data services in the cloud). Claims make role-based access control easier to administer because AD FS and other identity providers can issue claims that support a variety of authorization checks at the RP.
This article demonstrates how you can use claims to enable secure user authentication from a wide variety of devices. Users have come to expect anytime, anywhere access to enterprise resources. IT is obligated to perform a delicate balancing act.
You have to enable the business with scalable infrastructure that supports mobile computing. At the same time, you have to protect the business with data-security mechanisms that are manageable and minimally intrusive.
.jpg "Tom Jones")
Tom Jones was the founding chair of the American National Standards subcommittee ASC X9A10 on electronic payments. He has worked within the financial services community with multiple organizations including Electronic Data Interchange (EDI X12) and Accredited Standards Committee X9 Inc. on electronic payments, as well as with First Data Corp., Intel Corp. and Microsoft.
.jpg "Dan Griffin")
Dan Griffin* is the founder of JW Secure Inc. and a Microsoft Enterprise Security MVP. He’s the author of the books Cloud Security and Control and *The Four Pillars of Endpoint Security. He is also a frequent conference speaker and blogger.