Microsoft has entered the cloud and customers are looking into moving their applications to this new platform. In doing so authentication and identity management needs to be addressed. InfoQ Editor Jon Arild Tørresdal talked to Eugenio Pace, Senior Program Manager in the Patterns & Practices team about the recent federation and identity technologies released from Microsoft.

Federation is however not only valuable in the cloud, but also interesting for companies looking to federate with partners or enable single sign-on across applications. For developers or IT professionals looking for more information about federating on the .NET platform, InfoQ have collected a set of resources that might be helpful, and can be found at the end of this article.

InfoQ: Could you give us a brief description of federation and which challenges it’s addressing?

Eugenio: Many applications today take the responsibility of authenticating its users. They do this by managing user credentials, usually in the form of username/passwords or some other shared secret. The result is a proliferation of user accounts repositories, one on each application. In many situations this is just fine, but in many other scenarios this approach has many limitations. For example: if each application stores user accounts in its own database, then it is very difficult to provide a “Single Sign on” experience. There are also increased management tasks, like creating new user accounts as you have to do so on each application. There’re also increased security risks: if a user is not valid anymore you might forget to disable his account from one of the applications and inadvertently allow access when you shouldn’t. Identity Federation (and the related claims based authentication architecture) aims at solving all these challenges by factoring out user authentication from applications and moving it to a specialized service: an “identity provider”.

InfoQ: Federation in .NET has previously been hard to accomplish and required a high degree of security knowledge to get right. What have Microsoft done to change this?

Eugenio: Microsoft has recently released the Windows Identity Foundation (WIF), a .NET library to “claims enable” .NET applications. WIF provides higher level abstractions that significantly lowers the bar of entry to the world of Identity Federation and Claims. WIF ships with an SDK and tools integrated into Visual Studio to simplify even further the development experience.

InfoQ: Where would you say that federation would get its biggest adoption or have the greatest benefit?

Eugenio: One of the key scenarios where identity federation shines, is for cloud based applications. I believe that as companies move more and more applications to the cloud, a claims based approach to identity will be the preferred approach.

Eugenio: The goal of the guide is to help developers quickly understand the benefits of claims based identity. The book describes very common scenarios (like SSO, Federation with multiple partners, federation with Web Services), their specific considerations and the design you can use to address their specific requirements. The ultimate goal is to accelerate the adoption of claims based identity.

InfoQ: You’ve mentioned claims. As far as I know claims have existed in .NET since v. 1.0 but have not been actively used by many. Now claims seem to be a central part of the identity model in .NET. Could you give us a brief description of the claims model and how it differs from more traditional models?

Eugenio: WIF is designed to abstract developers away from all the details of validating, parsing and exchanging security tokens. It implements WS-Federation and WS-Trust protocols and can handle SAML 1.1 and 2.0 security tokens. Developers will mostly deal with higher level abstractions such as IPrincipal and IIdentity. WIF provides specialized versions of these: IClaimsPrincipal and IClaimsIdentity.

InfoQ: What else can you tell us about the WIF framework?

Eugenio: WIF is seamlessly integrated into common and popular application stacks such as ASP.NET for web sites and WCF for web services. For many scenarios, developers will simply use the abstractions that they were already familiar with, like the IPrincipal interface. WIF will automatically wire up concrete claims based implementations at runtime. For example, in an ASP.NET application, developers can continue to call User.Identity.Name, where the Identity property is actually an IClaimsIdentity and Name will be a property extracted from the claims collection. Tools integrated into Visual Studio allow developers to automatically convert existing applications to use claims. An example of this is the “Add STS Reference” wizard in Visual Studio to “claims enable” a web application.

InfoQ: ADFS 2.0 is Microsoft’s STS integrated with Active Directory. Currently (as its name implies) only support Active Directory. Do you think ADFS will stay a pure STS for AD or can we expect other integration points?

Eugenio: ADFS v2 can currently authenticate users against AD only. However, ADFS v2 supports rich and extensible engine for issuing claims that can use various attribute stores. Out of the box, ADFS v2 can issue claims from information stored in LDAP directories and SQL repositories. You can also develop your own custom attribute provider.

InfoQ: ADFS have an optional proxy giving users the ability to authenticate in their company domain over the internet. I’ve found it hard to convince IT that this is secure. Could you elaborate on how this proxy works and say something about its recommended usage?

Eugenio: Every scenario is different, so specifics of each customer requirements have to be analyzed. The primary scenario is the one you describe. The proxy is meant to provide an additional security layer on top of your internal STS. The proxy can be extended to implement multi-factor authentication and further strengthen the authentication requirements of internet users.

InfoQ: I know ADFS 2.0 have support for SAML tokens today. Does it also support the SAML protocol?

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.