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.
