Here's a common scenario: You have developed a Web site that requires a log-in. However, rather than promoting your site to individuals who sign up and create their personal log-in, you promote the site to entire companies. A company with thousands of employees signs up to use your site and you are suddenly faced with the need to re-create thousands of accounts on your server. Users, when accessing the site, must perform the most frustrating task: logging in with a different account. You sit back and think, "There must be a better way."
Well, that is only one of many scenarios where people in one company need to access items in another company or have a single sign-on for another site, be it a SharePoint site or some other type that requires a log-in. Here is where it may be worth looking into ADFS (Active Directory Federation Services).
How ADFS works
Essentially, with ADFS, each company manages its own identities. But within a federated environment, each company can accept and provide permissions and/or access to identities from within another company. It all comes down to trust. The ability to trust accounts from one company without requiring a local account on your servers. This trust is called federated identity management and is the core behind ADFS. The biggest concern, logically, is security. All communication from one company's Active Directory to the other's ADFS is encrypted, and client access to through their browser is also encrypted using SSL.
It's important to mention that ADFS is only for Web-based applications (like SharePoint). It's really a solution only for allowing external business partners or clients to access your Web application, while still allowing the partner or client to manage their identities.
There are a few scenarios where you might use ADFS. One is the single sign-on where a person does have to log in one time through forms-based authentication, which will provide the users with a cookie that they can then use to access the rest of the site without having to provide repeat credentials. Another option is the identity federation option where they use their token from Active Directory to access the Web application without having to reauthenticate at all.
ADFS was released in Windows Server 2003 R2 but has received some important enhancements in the 2008 version, including the following:
- An easier installation as a server role with all the necessary services being automatically installed with the role itself such as ASP.Net and IIS)
- Tighter integration with ActiveDirectory RMS (Rights Management Services)
- ADFS works with MOSS (Microsoft Office SharePoint Server) 2007 with an easy-to-configure single-sign-on configuration for both intranet and extranet/Internet sites
ADFS configuration is not so simple
Explaining ADFS is easy, but the design and configuration of ADFS is a tad bit more complicated than I've made it sound so far. The design reading alone can take forever because you need to determine what you are truly looking to accomplish, and there are several methods to reach those goals. For example, do you want a Web single sign-on implementation, a federated Web single sign-on implementation, or a federated Web single sign-on implementation with Forest Trust? Knowing your goal is the key to getting started.
The implementation side depends not only on your design solution but also on the Web application you are looking to provide access to. Is it a SharePoint, which already comes with claims-aware features, or will you create your own claims-aware application?
Obviously, the world hasn't been waiting for Microsoft to release a federated services product before realizing the need here. So, most likely you have seen or worked with other solutions for single sign-on or some other form of cross-site authentication trust. We would like to know what you are using and how it measures up to ADFS.