Thursday, July 9, 2009

Active Directory Federation Services (ADFS)

Federated Identity is a standards based technology. IBM, SUN, and Versign all have stakes in this technology. ADFS is simply Microsoft's solution for Federation management.
ADFS is part of the R2 release of Server 2003. You cannot purchase or download ADFS separately.

So exactly what is ADFS?
ADFS is a service (actually a series of web services) that provides a secure single-sign-on (SSO) experience which allows a user to access multiple web applications spread across different enterprises and networks.

ADFS fills a much needed gap in the following scenarios:
Extranet Applications
Many organizations host at least one application used by business partners or other outside users. So we stand up this application and supporting infrastructure in our DMZ right? In most cases this involves at least an IIS Server, SQL Server, and something to authenticate and authorize users. If we plan on having more than just a handful of users using our application and need advanced user management then chances are we're going to put an Active Directory forest in our DMZ. Ok great. Now we just secure it all and create user accounts for our business partners and we're off and running. But wait... All of a sudden our internal users need access to the extranet application as well. So now what? We could create and manage a second user account for each internal user needing access (not to mention reset the user's passwords when they forget their DMZ account information). Our second option is to open up several ports and create a trust relationship between the two domains. This would give us the ability to provide extranet application access to the intranet AD users, however opening the required ports decreases our security and makes our internal AD environment more vulnerable to attack. This is where ADFS comes in.


ADFS gives us the ability to setup what's known as Federation Servers in our internal network and dmz. The federation servers then securely (via certificates and SSL) allow our internal AD users to acquire a "token" which in return gives them access to the extranet application. This prevents the internal user from having to enter any credentials just like the application was sitting on the internal network. This is all done without exposing internal account information to the DMZ.

B2B Extranet Applications
Now lets take ADFS to the next level. Remember the business partner we want to provide access to our extranet application? Remember how we put AD in the DMZ so we can setup user accounts for our partner? What if our application supports different levels of security? And what if we want to give each user from the business partner unique access to our application? Well all still fairly simple. We just setup and manage a user account for each of those user's in our DMZ domain right? What if our business partner decides they want all 1,000 employees accessing our extranet app. Well now we have an account management nightmare. This is where ADFS comes to the rescue again. With ADFS we can provide Federated access to accounts from our partner's active directory domain. We setup a federation server in our DMZ and our business partner does the same (once again encrypting communication over SSL). We then grant application access to what we call "claims groups" which map to real groups within our partner's domain. Our partner then simply places their domain's already created, and managed user accounts into their own group within AD and suddenly they are browsing our extranet application, with SSO I might add. Please note that credentials, SIDS, and all other AD account information is NEVER passed between federation servers (or organizations). Federation servers simply provide "tokens" to user accounts when they need to access the application on the other side.

Final Thoughts
ADFS is an exciting new technology that many vendors and companies are beginning to buy into. With that said keep in mind that it is a "new" technology as well. Be sure to look for future standard and protocol changes. You should also be aware that ADFS can be very complicated and confusing to setup the first time, however it can be simplified.

Please do NOT setup a production ADFS (especially in a B2B scenario) unless you have extensively tested and are comfortable with the security of your configuration. After all you are providing access to one of your applications, extranet or not. I would also suggest some sort of signed legal agreement between the two organizations in a B2B scenario. If you would like to see a followup post on how to setup ADFS please leave comments or email me informing me of your interest. Here are some followup links to get you started:

http://www.microsoft.com/windowsserver2003/default.mspx http://www.microsoft.com/WindowsServer2003/R2/Identity_Management/ADFSwhitepaper.mspx http://technet2.microsoft.com/WindowsServer/en/Library/050392bc-c8f5-48b3-b30e-bf310399ff5d1033.mspx

No comments: