Share via

Windows Azure Security Best Practices – Part 5: Claims-Based Identity, Single Sign On

  • Article

Windows Identity Foundation logoClaims-based identity is a simple but powerful way of handling identity and access for your web sites and web services, whether you work on-premises or you are targeting the cloud. You can create more secure applications by reducing custom implementations and using a single simplified identity model based on claims.

Windows Identity Foundation (WIF) is a set of .NET Framework classes. It is a framework for implementing claims-based identity in your applications.

Architecturally using claims-based identity gets your application out of the authentication business. Single sign-on is much easier to achieve, and your application is no longer responsible for:

  • Authenticating users.
  • Storing user accounts and passwords.
  • Calling to enterprise directories to look up user identity details.
  • Integrating with identity systems from other platforms or companies.

Instead your application uses a claim that arrives to your application as a security token from an issuing authority. A security token service (STS) is the plumbing that builds, signs, and issues security tokens according to the interoperable protocols. Your application is the relying party.

Claim.   A claim is some information that your application need to know about a user. For example, a user’s name or email address or in the sales organization. Your application will accept the claim from

Security Token. In a Web service, these claims are carried in the security header of the SOAP envelope. In a browser-based Web application, the claims arrive via an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired.

Issuing Authority is a Web application or Web service that knows how to issue security tokens. In the scenario of claims-based identity, the issuing authority is responsible for issuing the proper claims (such as name and email or whether the person is in the sales organization.)

Security Token Service (STS). STS is trusted by both the client and the Web service to provide interoperable security tokens.

Relying Party. That’s your application or Web service. You can see it described as claims aware application or claims-based application.

SAML Token. Most STSs today issue SAML (Security Assertion Markup Language) tokens. SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way.

Scenario

There are many scenarios. But in the one I chose, a user points her browser at a claims-aware Web application (relying party). The Web application redirects the browser to the STS so the user can be authenticated.

The STS, wrapped by a simple Web application that reads the incoming request, authenticates the user via standard HTTP mechanisms, and then creates a SAML token and emits a bit of JavaScript that causes the browser to initiate an HTTP POST that sends the SAML token back to the relying party.

The SAML token in the POST body contains the claims that the relying party requested.

image

Your application takes the SAML token and using Windows Identity Foundation, uses a few lines of code to open up the token and extract the claims. Now you have access to the requested data, such as name, email, and whether or not the person is in the sales organization.

There are many other scenarios. This one uses WS-Trust.

You don’t have to worry about what domain or security realm your user happens to be part of. In fact, you can support Facebook identity or Windows Live or Google ID or a claim from a user based on their active directory. Using claims based identity makes it a lot easier to federate identity with other platforms or organizations.

Windows Identity Foundation Object Model for Claims

When you build a relying party with WIF, you’re shielded from all of the cryptographic heavy lifting that WIF (and its underlying WCF plumbing) does for you. It decrypts the security token passed from the client, validates its signature, validates any proof keys, shreds the token into a set of claims, and presents them to you via an easy-to-consume object model.

In your code you ask the token for each claim you need.

Here’s a sample that returns an email address.

protected string GetUserEmail(object sender, EventArgs e)
{
IClaimsIdentity id =
((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0];

// you can use a simple foreach loop to find a claim...
string usersEmail = null;
foreach (Claim c in id.Claims) {
if (c.ClaimType == ClaimTypes.Email) {
usersEmail = c.Value;
break;
}

return usersEmail;
}

The code can assume that the assumed the caller was authenticated and that her and email address had been sent as claims. The reason this program can make these assumptions is because it has a web.config file that uses the WS-Federation Authentication Module (FAM) from WIF and configures it with the address of an STS that can authenticate the user and supply these types of claims.

FAM is an HttpModule that is specifically designed to make it easy to build federated claims-aware Web applications using ASP.NET 2.0.

So you need some information in your web.config that is explained in the Microsoft Windows Identity Foundation (WIF) Whitepaper for Developers.

WIF offers built-in Visual Studio project template for creating a claims-aware ASP.NET application or claims-aware WCF services. So you can have an excellent starting point.

Writing Your Own STS

You may already be maintaining a membership list of user names, names, and passwords. You can create your own STS to provide identity.

The STS  accepts incoming requests, validates, decrypts, and shreds incoming security tokens into claims, and does the opposite for outgoing security tokens. WIF takes care of all of that heavy lifting.

Note: WIF does not do provide a framework for managing or administering policy, which you can think of as the logic, or the rules, behind the STS.

Making ASP.NET Membership Provider Into an STS

If you are using ASP.NET Membership Provider, you can turn that into an STS and make it one of the providers your users can use to access your application. You can do this by adding a simple STS to you ASP.NET membership provider-based website. By adding a simple page containing WIF code you will enable your partners to accept your users in their websites, even enabling Single Sign On for the users already logged in your website. See Enhancing an ASP.NET Membership Provider Website with Identity Provider Capabilities.

Providing Single Sign On

Once your application uses claims, it is easier to add scenarios where you can use other ways to sign in. The application only cares that the token is provided by a trusted provider. And the STS provides the information the application needs, such a name, email, or whether the person is in the sales role.

Single sign-on (SSO) is where a user's token, is trusted across multiple IT systems or even organizations. You application can use a federated identity as the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.

In many of the scenarios, the STS that provides the user’s claim run inside the same organization as your application. But your application can now take advantage of an STS that is outside the organization.

As long as the application trusts the federation provider STS, that STS can run anywhere—even in the cloud.

Windows Azure Access Control is a federation provider STS that runs in the cloud. And when you connect to another organization, their Active Directory that could provide the token might not express a role in the same way as another. So Access Control has a straight forward way to map the roles of various providers into the names your application uses.

You can even allow log ins from other providers including Facebook, Google, Windows Live, or Yahoo.

I’ll describe Access Control in the next part of this series.

Context of Windows Identity Foundation

Windows Identity Foundation is part of Microsoft's identity and access management solution built on Active Directory that also includes:

  • Active Directory Federation Services 2.0 : a security token service for IT that issues and transforms claims and other tokens, manages user access and enables federation and access management for simplified single sign-on.
  • Windows Azure Access Control Services: provides an easy way to provide identity and access control to web applications and services, while integrating with standards-based identity providers, including enterprise directories such as Active Directory, and web identities such as Windows Live ID, Google, Yahoo! and Facebook.

Getting Started with Windows Identity Foundation

References

Brokered Authentication: Security Token Service (STS)

Windows Identity Foundation (WIF)

Next Up

Windows Azure Security Best Practices – Part 6: How Azure Services Extends Your App Security. In this last part I show how other services in Windows Azure provide secure identity mapping, messaging, and connection to on premises application. This section describes the implications of Windows Azure Active Directory, Windows Azure Connect, and Service Bus for cloud applications, on premises applications, and hybrid applications.

Here are links to the articles in this series:

 

Bruce D. KyleISV Architect Evangelist | Microsoft Corporation

image