One of the most exciting new features in Microsoft’s forthcoming R2 release of Windows Server 2003 is the Active Directory Federation Services (ADFS). ADFS is a single sign on technology that can be used to authenticate a user into multiple Web applications over the course of a single session. In this article, I will explain the key features of ADFS and how ADFS works.
What is ADFS?
ADFS extends Active Directory to the Internet. To understand what this means, think about how a normal Active Directory deployment works. When a user authenticates into an Active Directory environment, a domain controller checks the user’s credentials. Once users have been validated, they are free to access any resource on the Windows network (assuming they have permissions) without having to re-authenticate every time they access a different server.
ADFS applies this same concept to the Internet. We have all seen Web applications that access back-end data located on a SQL Server or on some other type of back-end resource. The challenge has always been providing secure authentication to those back-end resources. There are a few different authentication methods that traditionally have been used to provide this authentication. For example, users might authenticate into the application via a RADIUS (Remote Authentication Dial-In User Service) server or through a proprietary authentication mechanism that is a part of the application’s code.
Although these types of authentication mechanisms get the job done, they do have some drawbacks. One drawback has to do with account management. Account management isn’t usually a huge deal if the application will be accessed by your own employees, but what if your suppliers or your clients are going to be the ones accessing the application? All of a sudden you find yourself having to set up user accounts for employees of these other companies. Furthermore, there is the ongoing maintenance issue. When employees of these other companies quit and new employees are hired, you have to delete old accounts and create new ones. Passwords become an issue, too. You may find that once the application is deployed, your help desk stays a lot busier with password resets for people who do not even work for your company.
What can ADFS do for you?
What if you could shift the burden of account management to your clients, suppliers or whoever it is that uses your Web application? Imagine, if you will, a Web application that services employees from other companies, and you never have to create user accounts or reset passwords for those employees. As if this isn’t impressive enough, the people using the application never even have to log into the application. Sound too good to be true?
The main idea behind this technology is that you can create cross-forest trusts and extend that trust to Web applications. For example, suppose that you have a supplier who needs to access a Web application that you host. Rather than you having to setup and maintain a bunch of user accounts for your supplier, they could create a security group in their own Active Directory. That group would contain all of the users who need access to your Web application. Then, you simply grant application access to that group. It doesn’t matter that the group exists in a completely different Active Directory forest from the one that the Web application is hosted in. Now, when users on your supplier’s network attempt to access your Web application, they do not have to log into it. The application automatically authenticates the users based on their group membership.
Of course this is just an example of how you could set up a federated trust. R2 is not out yet and there is not presently a lot of information available on the ADFS configuration process. The actual configuration might be a little bit different than what I just described, but the general principle should be on track.
What does ADFS need?
Of course Active Directory Federation Services doesn’t happen by magic. To take advantage of it, you will have to have servers performing specific roles. One of the primary roles that must be filled is the federation server. The federation server hosts the federation service component of ADFS. The federation server’s job is to route requests that come in from external users. The federation server is also responsible for issuing tokens to users upon successful authentication.
Another role that is required in most situations is a federation proxy. Think about it for a minute. If an external network were to be able to establish a federation agreement with your network, it would mean that your federation server would have to be accessible over the Internet. Since Active Directory federation is so heavily dependant on the Active Directory, exposing the federation server directly to the Internet would be a huge security risk. So, instead, you would place a federation proxy at the perimeter of your network. This proxy would relay federation requests from the outside world to your federation server. And your federation server is not exposed directly to the outside world.
One other major component involved in ADFS is the ADFS Web agent. A Web application must have a mechanism for authenticating external users. This mechanism is the ADFS Web agent. The ADFS Web agent manages the security tokens and authentication cookies that are sent to the Web server.
As you can see, ADFS will greatly expand what can be done with Web applications. It will be interesting to see how ADFS is actually put to work in the real world once R2 is released.
Filed under: Windows 2008
