Introduction

Active Directory Federation Services (ADFS) is based on the emerging, industry-supported Web Services Architecture, which is defined in WS-* specifications.

ADFS is a component in Microsoft® Windows Server™ 2003 R2 that provides Web single-sign-on (SSO) technologies

• To authenticate a user to multiple Web applications
• Over the life of a single online session

ADFS accomplishes this by securely sharing digital identity and entitlement rights, or "Claims," across security and enterprise boundaries.

ADFS is not:

• A database or repository for employee or customer identity data
• An extension of the Active Directory™ directory service schema
• A type of Windows domain or forest trust

Key features of ADFS

Federation and Web SSO: When an organization uses the Active Directory™ directory service, it currently experiences the benefit of SSO functionality through Windows-integrated authentication within the organization's security or enterprise boundaries.

ADFS extends this functionality to Internet-facing applications, which enables customers, partners, and suppliers to have a similar, streamlined, Web SSO user experience when they access the organization’s Web-based applications.

Web Services (WS)-* interoperability: ADFS provides a federated identity management solution that interoperates with other security products that support the WS-* Web Services Architecture.

Extensible architecture: ADFS provides an extensible architecture that supports the Security Assertion Markup Language (SAML) token type and Kerberos authentication (in the Federated Web SSO with Forest Trust scenario).

Active Directory, Domain, Trust and Forest

Active Directory is a centralized and standardized system that automates network management of user data, security and distributed resources and enables inter-operation with other directories. Active Directory is designed especially for distributed networking environments.

Active Directory is a centralized and standardized system that automates network management of user data, security and distributed resources and enables inter-operation with other directories. Active Directory is designed especially for distributed networking environments.

Windows Server 2003 Active Directory provides a single reference, called a directory service, to all the objects in a network, including

• Users
• Groups
• Computers
• Printers
• Policies
• Permissions

Active Directory networks are organized using four types of divisions or container structures. These four divisions are forests, domains, organizational units and sites.

Forests: The collection of every object, its attributes and attribute syntax in the Active Directory.

Forests are not limited in geography or network topology. A single forest can contain numerous domains, each sharing a common schema. Domain members of the same forest need not even have a dedicated LAN or WAN connection between them. A single network can also be the home of multiple independent forests. In general, a single forest should be used for each corporate entity. However, additional forests may be desired for testing and research purposes outside of the production forest.

Domain: A collection of computers that share a common set of policies, a name and a database of their members.

Domains serve as containers for security policies and administrative assignments. All objects within a domain are subject to domain-wide Group Policies by default

Furthermore, each domain has its own unique accounts database. Thus, authentication is on a domain basis. Once a user account is authenticated to a domain, that user account has access to resources within that domain.

A domain must have one or more servers that serve as domain controllers (DCs) and store the database, maintain the policies and provide the authentication of domain logons.

With Windows NT, primary domain controller (PDC) and backup domain controller (BDC) were roles that could be assigned to a server in a network of computers that used a Windows operating system.

The user need only to log in to the domain to gain access to the resources, which may be located on a number of different servers in the network.

One server, known as the primary domain controller, managed the master user database for the domain. One or more other servers were designated as backup domain controllers. The primary domain controller periodically sent copies of the database to the backup domain controllers. A backup domain controller could step in as primary domain controller if the PDC server failed and could also help balance the workload if the network was busy enough.

Organizational units: Containers in which domains can be grouped. They create a hierarchy for the domain and create the structure of the Active Directory's company in geographical or organizational terms.

Organizational units are much more flexible and easier overall to manage than domains. OUs grant you nearly infinite flexibility as you can move them, delete them and create new OUs as needed. However, domains are much more rigid in their existence. Domains can be deleted and new ones created, but this process is more disruptive of an environment than is the case with OUs and should be avoided whenever possible.

Sites: Physical groupings independent of the domain and OU structure. Sites distinguish between locations connected by low- and high-speed connections and are defined by one or more IP sub-nets.

By definition, sites are collections of IP sub-nets that have fast and reliable communication links between all hosts. Another way of putting this is a site contains LAN connections, but not WAN connections, with the general understanding that WAN connections are significantly slower and less reliable than LAN connections. By using sites, you can control and reduce the amount of traffic that flows over your slower WAN links.

Domain is territory over which rule or control is exercised; most organizations that have more than one domain have a legitimate need for users to access shared resources located in a different domain.

Controlling this access requires that users in one domain can also be authenticated and authorized to use resources in another domain. To provide authentication and authorization capabilities between clients and servers in different domains, there must be a trust between the two domains.

Trusts are the underlying technology by which secured Active Directory communications occur, and are an integral security component of the Windows Server 2003 network architecture.

Trusts help provide for controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority (the trusted domain).

In this way, trusts act as bridges that allow only validated authentication requests to travel between domains.

Types of trust relationships:

ONE-WAY, providing access from the trusted domain to resources in the trusting domain

TWO WAY, providing access from each domain to resources in the other domain

NONTRANSITIVE, trust exists only between the two trust partner domains

TRANSITIVE, trust extends to any other domains that either of the partners trusts

In some cases, trust relationships are automatically established when domains are created; in other cases, administrators must choose a type of trust and explicitly establish the appropriate relationships.

Group Policy management and Active Directory

It's difficult to discuss Active Directory without mentioning Group Policy. Admins can use Group Policies in Microsoft Active Directory to define settings for users and computers throughout a network. These setting are configured and stored in what are called Group Policy Objects (GPOs), which are then associated with Active Directory objects, including domains and sites. It is the primary mechanism for applying changes to computers and users throughout a Windows environment.

Through Group Policy management, administrators can globally configure desktop settings on user computers, restrict/allow access to certain files and folders within a network and more.

ADFS 2.0, which was released in early May, "doesn't require changes to Active Directory server -- it's a separate server that knows how to talk to Active Directory,"

ADFS 2.0 is a central piece of Microsoft's identity management strategy, providing a two-way gateway for sending and receiving claims-based requests, as Microsoft calls them, using SAML-based tokens containing information about users and what they want in terms of information and access.

ADFS 2.0 supports the open standard protocol Security Assertion Markup Language (SAML) 2.0,

"SAML interoperability is built into ADFS 2.0,"

ADFS 2.0 is expected to be baked into many future Microsoft application products, such as SharePoint 2010. But the reality is today legacy applications don't have the ability to easily work under a SAML-based framework, though they can be made to work that way.

"Policy framework is not part of ADFS 2.0,"

The authorization protocol Extensible Access Control Markup Language (XACML) from the Organization for the Advancement of Structured Information Standards (OASIS) has emerged as the preferred standard for fine-grained authorization.

IBM says it supports XACML in its Tivoli Federated Identity manager product. But it's unclear if Microsoft is going to go the XACML route

Claims-Based Identity Model

When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the user’s name, another might be an e-mail address. The idea here is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.

Under this model, single sign-on is much easier to achieve

Under this model, your application makes identity-related decisions based on claims supplied by the user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher valued features and resources in your application.

Security Token

The user delivers a set of claims to your application along with a request. In a Web service, these claims are carried in the security header of the SOAP envelope. In a browser-based Web application, the claims arrive through an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired. Regardless of how these claims arrive, they must be serialized, which is where security tokens come in. A security token is a serialized set of claims that is digitally signed by the issuing authority.

Claim

Think of a claim as a piece of identity information such as name, e-mail address, age, membership in the Sales role. The more claims your application receives, the more you’ll know about your user.