Active Directory Federation Services (ADFS) for ASP.NET 2.0 Developers

This post is to inform you of a couple new screencasts on Channel9 hosted by Keith Brown. In these, Keith drills into the role AD FS can play in helping you architect/develop claims-based Web applications which offer their Internet users not only a Web SSO experience, but supports user access by federation partners as well. Both are much needed in today’s Web applications!

For some time now developers have built Web applications around a domain or application-based identity infrastructures to provide user access to their applications. In the domain-based Windows environment, Windows integrated authentication has worked its magic on the user’s behalf by extending their single, interactive authentication event to a host of applications and services providing the user with a single signon (SSO) experience. But, this has one catch, a domain-based identity infrastructure retains absolute authority over the identities within its domain and let’s no others in. It creates users and services and makes all the trust decisions for them within its borders, that is, within the firewall. However, as the business need for ubiquitous user access has evolved, the demand upon Web applications is to no longer only support users inside the firewall. Potentially, these same applications, or portions of them, need to now be accessed by vendors, partners or customers as well. How do you provide access for these users to applications built around the domain-based identity model? At the minimum, it infers additional user account management. Each one must have a domain-based identity inside the firewall. If this means hundreds or potentially thousands of additional user accounts, it’s a further burden on IT and helpdesk staff to manage password resets and provisioning/de-provisioning of accounts for those loosely affiliated with the organization.

Federation:

Active Directory Federation Services (AD FS) (In Windows Server 2003 R2 and 2008) enables the cross-domain reach of your Web applications while preserving a Windows Integrated Authentication experience inside the firewall and providing a SSO experience across Web applications for those outside the firewall. Furthermore, AD FS makes additional user account management unnecessary because it provides an infrastructure for establishment of federation trust relationships with partner organizations. Due to the federation trust relationship, accounts from the partner’s domain can be trusted to have access to specific applications within your domain. Therefore, in a federated trust model, each organization continues to manage its own domain-based identities, but they can also securely project and accept these digital identities, including their associated access rights, into or from other partner organizations.

So what are the advantages of moving to this cross-domain, federation trust model for identities? First, from a SSO perspective, AD FS manages this for your AD FS enabled Web applications. AD FS maintains SSO for any Web application relying on it to broker authentication events via the pre-established federation trust relationships. After the user’s initial authentication, if they navigate to other AD FS enabled Web applications that are under the same federation trust, the user experiences SSO with these applications as well. Secondly, from an architect’s and developer’s perspective, with AD FS in the mix, you can design and build your applications with the intent that they may be accessed by anyone. Essentially, write the application once, but fully anticipate its use by users from multiple security domains – again, some from inside the firewall and others from outside. And, because AD FS is based on the open standard WS-Federation protocol, it can also broker access to your application from any non-Microsoft platform that implements WS-Federation. This further extends the reach of your federation-aware application.

The next logical question is, if you decouple the authentication event from the application, how does the application get the information it needs to make its access control decisions? As mentioned above, the cross-domain digital identities also can contain access rights, asserted in the form of claims that the application can consume. The application can use these claim values to enforce its internal access control decisions. A very handy technology for mapping access rights to roles is Windows Authorization Manager (AzMan). I’ve already discussed AzMan in previous blogs, but its role-based access control (RBAC) capabilities can be employed in the claims-based programming model that AD FS uses. Hence, the purpose of this blog. To introduce you to the Channel9 screencast series focusing on claims-based programming with AD FS, hosted by Keith Brown. Please follow the links below.

Enjoy!

Active Directory Federation Services (AD FS) Part 1 by Keith Brown
Active Directory Federation Services (AD FS) Part 2 by Keith Brown