Kotan Code 枯淡コード

In search of simple, elegant code

Menu Close

Multi-Domain Federation with ADFS v2.0

I realize that the title of this post might not be the most fascinating post but, I try to make it a point to post about things that I think will inform other developers and there are a lot of developers working on federated security right now, especially those attempting to bridge the gap to the cloud either  by moving to Azure or creating Azure-Enterprise hybrids.

Before I get to the how of this, let’s talk about the why. Why is this elegant or simple? Under the hood it is anything but simple, but the developers of individual applications within your enterprise as well as developers of partner applications will thank you for this and it does make this far simpler.

There are a couple of scenarios here, but I’ll talk about the two major ones (other scenarios are usually just variants/combinations of the below):

  1. Federation with Business Partners. In this scenario there are external business partners to whom you wish to grant access to your web app.
  2. Federation of related applications within the same enterprise, also enabling SSO. In this scenario your enterprise has many web applications and multiple active directory domains and you wish to allow anyone from either domain to access any of the web applications.

In my case I had to create something like #2, although the fact that #1 becomes possible “for free” didn’t hurt. In my scenario I had a full-blown enterprise domain that was managed by the IT people and I had a separate active directory in which customer accounts were stored and against which customers needed to authenticate. The goal here was to provide a unified interface so that internal employees and external customers authenticated against the other domain would have the same SSO login screen. ADFS let me do that, and it actually wasn’t all that difficult once I got advice from the right people and got the hang of the terminology.

So, before I get into how I got ADFS to federate authentication of all my enterprise web applications across two domains, let’s run through some terms. If you know this already, feel free to skip ahead to the good stuff:

  • Relying Party Trust – A relying party is an application that relies on the federated security system for authentication and authorization. The application agrees to give up isolated management of user information and permissions and trusts that the federated system will take care of those details. It becomes passive and expects that information about the user’s identity and permissions will come across as claims.
  • Claims Provider Trust – Claims Provider trusts are essential for multi-domain federation. This is basically a trust relationship where you are telling your ADFS configuration that you trust that a specific set of claims can come from an external ADFS server (or other standards-compliant token server). Here we might create a claims provider trust from the employee ADFS to the customer ADFS, but I’ll explain more on that later.
  • Attribute Store – Attributes are bits of information that can be returned to relying parties in the form of claims. ADFS comes pre-configured to use Active Directory as an attribute store. This lets you return claims for first name, given name, e-mail address, etc. You can also create custom attribute stores or use SQL server.

When you’re looking at the ADFS configuration, you’ll see a tree menu on the left that you can use to build these trust relationships and configure these stores:

ADFS Configuration Tree

ADFS Configuration Tree

When you configure a relying party trust, and then add claims rules (a topic for yet another post), you will be able to authenticate that website using the ADFS server instead of a mechanism built into that website.

When you have a Claims Provider Trust pointing from one ADFS server to the other, ADFS will actually bring up a screen that allows the user to choose which ADFS server they want to use for authentication. If you give them friendly descriptions, you can have the ADFS server prompt users to choose between things like Internal Employee and Customer.

The tricky part here is you have to pick the one ADFS server to serve as the one that all the applications use in their Web.config files. This server will then examine its configuration and if it is possible to get claims from another provider for a particular relying party, it will prompt the user with a dropdown. The other tricky part is that on the second ADFS server (in my case, the Customer ADFS server), you need to have a relying party configuration that points back to the Employee (or ‘master’) ADFS server.

So, to recap:  You have web applications (ASP.NET/ASP.NET MVC in my case, but they can be other frameworks) that give up their own right to manage their own authorization and authentication. In doing so, they point to a central or master ADFS server within their Web.config files. This central ADFS server has a list of Claims Provider Trusts that is basically a list of all other external (either in-building or out on the internet) ADFS servers that can provide claims. The end user, when prompted to authenticate, chooses which of these ADFS servers they want to authenticate against (they see the friendly display name, e.g. ‘Customer’ or ‘Employee’ or ‘Vendor’ or ‘Supplier’ etc). The authentication takes place on the appropriate ADFS server and then tokens get bounced around over HTTP and as cookies until the user is finally taken back to the secure website.

The end result is that you can have a bunch of web applications within your enterprise, out in the cloud, or within partner enterprises that can all share a pool of user credentials for authentication and authorization without any information ever leaving its own privacy scope. Business A can use an application hosted by Business B and that application can ask the web user whether they are a Business A or Business B user and authenticate them properly.

I realize that it took an awful lot of words to explain this and walk through how this kind of configuration works, but it’s for a good cause. What I’m trying to get at here is that the days of having to build a plethora of applications, each of which having their own private silo of user information, are gone. Tools like ADFS give us the ability to create suites of interconnected apps within our enterprise as well as allow users from outside the enterprise to use these applications without incurring huge maintenance overhead with complicated nightly user-FTP jobs to synchronize accounts, etc.