Shibboleth
and ADFS
Some
detailed documentation on ADFS configuration (but not protocol elements) has
finally appeared in a public
location (added to Microsoft downloads on 5/25). There is a public Beta of
Windows 2003 R2 to which it applies.
Domains
Microsoft
originally tried to distribute LANMAN through partners like 3COM, IBM, and DEC.
At the time it did not regard Networking as a strategic issue, but it did not
want Novell to dominate the technology. Microsoft maintained the client system
modifications and developed a high level protocol that could run over any network.
DEC took that protocol and hosted it on DECNet, using VAX VMS as the server.
AT&T took the same starting point and hosted it over an OSI stack using
System V as the server. IBM ran the protocol over Token Ring to an OS/2 server.
However,
none of these products was particularly successful, and one by one the partners
dropped out. This left Microsoft in 1993 to relaunch its own end-to-end
solution based on Windows NT 3.1. By that point the number of supported
protocols had been reduced to a local broadcast technology (Netbeui), Novell
IPX, and TCP/IP.
Due to
the small size of servers and the limited scope of broadcast protocols,
Microsoft targeted its networking technology at departments. Small numbers of
users and a compact geographical distribution were assumed. To scale up to
larger organizations, departments could establish "Trust"
relationships that would allow a resource owner in one departmental domain to
include a userid defined in another department in an Access Control List.
Active
Directory
By 2000,
TCP/IP was now the only important communications protocol. Microsoft now had
Servers large enough to support much larger groups of users, but it needed
protocols that could scale better. It decided to replace its own system of
simple machine names with the Internet DNS name system. It's Domain Controllers
would now communicate using LDAP. Authentication would use Kerberos 5.
Active
Directory gathered up the various departmental domains of previous Microsoft
networking into an Enterprise
networking structure. The various local domains at Yale became elements under
the common *.yale.edu DNS suffix. If everything at Yale ends in that suffix,
then the entire organization falls under one DNS "tree". However, a
university also has attached research institutes and non-profit organizations
and non-profit organizations that, for $10 a year now, can have their own
domain names. To allow the institution to have several DNS domain suffixes, the
AD unit is called a "Forest".
However,
the individual Domains retain their identity and their ability to create user
accounts and own machines. When the new protocols were added, each Windows
Domain became a Kerberos 5 realm, and the Domain Controllers became KDCs.
Kerberos had a protocol for trust relationships between realms. However, a
single Kerberos server could easily handle an entire university or corporation,
so actual use of the cross-realm protocol was not common. Because Microsoft had
started with a federation of departmental domains, its new system was
completely dependent on the routine use of cross-realm Kerberos 5 protocols.
Each
machine belongs to and has an account in one domain. Each user has an account
in a domain. In common practice, the machine belongs to a different domain than
the users. So when each user sits down at his desktop to logon each morning,
this request may be processed as a cross-realm Kerberos 5 transaction where the
user first logs on to the domain with his account, then gets a Service Ticket
to introduce himself to the domain that manages his machine, and finally gets a
Service Ticket that allows him access to his own machine.
In the
old days, a user might be known as "YALE\GILBERT" (userid
"GILBERT" in domain "YALE"). The domain was now
"yu.yale.edu", but there was now some confusion about the official
global name of the account. Since the native directory protocol had become
LDAP, there was strong technical reason to suggest that the official name of
the account was the completely unreasonable distinguished name
"CN=gilbert, CN=Users, DC=yu, DC=yale, DC=edu". Something a lot
easier to remember was needed, and if an alias was going to be developed there
was no particular reason why it had to accurately include a particular
departmental domain name.
Thus the
Universal Principal Name (UPN) was created. Any user in the *.yale.edu family
of domains (the "Forest" in AD
terms) could be given a unique global alias name in the form prefix@dnsname.
The prefix could be anything you wanted, but a choice like
"Howard.Gilbert" makes sense. The suffix had to be any DNS domain
name anywhere in the forest, but it didn't have to be the particular domain in
which the account actually resides. Thus, although "gilbert" is an
account in "yu.yale.edu", the UPN could be
"". This also happens to be an E-Mail alias
for the same person, and just as the UPN doesn't include the name of the domain
that includes the account, the E-Mail alias doesn't include the name of the
post-office machine that will actually process the mail.
Forest Trust
Starting
with Windows 2003, Microsoft tried to develop a protocol by which tightly
coupled institutions could federate identity systems. The good news was that
this system of "Forest Trust" was based on the same strong
technologies (LDAP, Kerberos 5) as the rest of Active Directory. The bad news
was that it required communication from the clients in one organization to the
Domain Controllers in the other. That would require poking too many holes in
the firewall. Thus this technology could be used only by very tightly coupled
organizations.
However,
one part of the Forest Trust protocol overlaps later approaches to identity
Federation. To identify a user outside his own institution, Microsoft decided
to use the UPN.
If
everyone is using UPN in a sensible way, then there is no problem. Certainly
the UPN of everyone at Yale ends in "yale.edu". If that is true for
every other school, then these become global names that make sense everywhere
in the world. It was always possible for Yale to decide, for whatever reason,
to define a "harvard.edu" suffix inside its Forest
and start to give out UPNs with that ending. At that point the UPNs are
hopelessly local and the Forest cannot
reasonably federate with other schools. As long as UPNs end in a name that is
legitimately assigned to the institution through DNS, then a global Federation
is possible.
Should
Yale and UCLA decide to establish Forest
trusts, and should the administration decide to poke enough holes in the
firewalls to allow this to occur, when the two Forests are initially introduced
to each other, they exchange all the UPN suffixes that they currently use. UCLA
would learn that anything ending in "yale.edu" belongs to Yale, and
Yale would learn that anything ending in "ucla.edu" belongs to UCLA.
They might each pick up a few extra DNS endings belonging to affiliated
organizations that are part of each Forest.
ADFS
Admitting
that Forest Trust requires too big a hole in the firewalls, Microsoft is
launching a second attempt with Windows Server 2003 R2. The bad news here is
that it cannot use the powerful protocols like LDAP and Kerberos 5 on which the
local network authentication is based. The good news is that ADFS is based on
SAML, SOAP, and the WS-Federation standard.
Unfortunately,
the names get changed. The "ID Provider" becomes the "account
partner". The SP becomes the "resource partner". The assertions
and attributes become "claims". Now if an application wants to deal
with this natively, it can write a "claims aware" authentication
front end using .Net Framework 2.0. However, since existing Windows
applications are used to making decisions based on users and groups, the
alternative is to create shadow accounts.
To keep
foreign accounts rationally separate, most institutions will probably decide to
put them in their own Domain. The big deal, however, is to give them a sensible
UPN. To do this, the current recommendation from Microsoft is to create within
your own Forest a UPN suffix for any external
institution with which you intend to federate. Thus if Yale and UCLA agree to
federate using ADFS instead of Forest Trust, Yale would create a UPN suffix of
"ucla.edu" within its own Forest and associate it with foreign
accounts belonging to users from UCLA.
Obviously,
you are in deep, deep s**t if you run ADFS for some time with shadow accounts
and then decide to establish a Forest Trust. You have to tear down everything
you have created. On the other hand, if you establish a Forest Trust first and
then add ADFS, things sort themselves out automatically (instead of using shadow
accounts, each Forest can use the real accounts in the other Forest
even though the authentication is being provided by SAML instead of Kerberos).
Since
Shibboleth is a "claims aware" application, it does not require any
shadow accounts or UPN fiddling to interoperate with ADFS. However, since the
entire Windows security system is based on accounts, it is likely that most of
the Microsoft documentation will deal with UPN mapping or other forms of
claim-to-shadow-account mapping.
Configuration
On the IdP
end, the ADFS is outside the firewall, visible to the world through HTTPS. It
turns AD authentication into SAML assertions. We may assume that it uses
Attribute Push. The only curious feature is instructions to generate the
signing certificate with "CN=Token Signing Certificate for entityname
FS".
There is
a Trust configuration database that is an XML file, but is typically edited
through a GUI management snap-in.
Metadata
is therefore generated partner by partner. An administrator at the IdP exports
its Token Signing Certificate to a portable format and E-Mails (or otherwise
distributes it) to the various SPs. They run the Add Account Partner Wizard to
create a new Account Partner entry and import the certificate. There are
configuration options for ARP and AAP based on the assumption that all
attributes are in the standard AD schema.
The rest
is mostly Claims mapping (to shadow accounts).
