Organizations in today's global
market have found themselves needing to extend their applications
beyond the corporate LAN. Many organizations find themselves needing to
securely provide clients, vendors, and business partners access to
their internal applications or extranets. Additionally, organizations
looking at cloud services to host applications are finding it necessary
to provide a secure single-sign onto these environments. These needs
create a lot of questions around security and account management.
Microsoft created Active Directory Federation services (ADFS) as a
solution to this issue. ADFS was first introduced with the release of
Windows Server 2003 R2 and has been further improved in Windows Server
2008. ADFS uses what is known as claims-based authentication to provide
a mechanism to authenticate across network boundaries. The claims-based
authentication is done by passing tokens between ADFS servers in
separate AD domains. The ADFS servers are set up to act as account and
resource servers which can authenticate users based upon a claims token
that is passed between ADFS servers and presented to the claims aware
application. ADFS is still considered an early technology, but if you
have applications where single sign-on is required across networks, you
should consider deploying ADFS. By using ADFS, you can allow users in
other organizations or other nontrusted forests in your organization to
access claims aware applications on your network. The two primary
scenarios where ADFS is used today are:
-
Extranet applications—It is common for
businesses to deploy an application such as SharePoint server in an
extranet or perimeter network. The problem created by doing this is
that most perimeter networks do not have direct access to the internal
AD environment. This means internal users need a second account and
password to log on to the perimeter application. This means that more
account management burden on IT departments and internal employees have
another set of credentials to remember. By deploying ADFS, you can
enable claims-based authentication in the extranet SharePoint
deployment which allows internal users to log on using their internal
AD accounts.
-
Business-to-business (B2B) extranet
applications—You may also want to consider using ADFS for extranet
applications that are heavily used by business partners, clients, or
vendors. In the B2B scenario, you use claims-based authentication to
allow users from business partners to log on to the extranet
application using the AD accounts from their own internal domain. This
not only provides a single-sign-on (SSO) experience to the end users
from the business partner, but puts the burden of account management
back on the business partner's IT department. In the B2B scenario, you
still control which users from the business partner have access to the
application, you just allow the other organization to maintain and
manage the accounts used to log on. This also helps ensure that
employees who no longer work for the business partner have their access
properly removed from your application.
ADFS will continue to evolve with future
releases of Windows. More focus will be given around enhancing
claims-based authentication for cloud-based services allowing your
corporate users to log on to a cloud service using the same credentials
they would use to access resources on your LAN.
1. Planning for Active Directory Federation Services
Prior to deploying ADFS, you should properly
plan your environment and ensure that the business requirements will be
met by your proposed solution. For example, if you want to provide SSO
for an extranet application in your permiter network, you will need to
ensure that your design includes an AD forest and ADFS servers in the
permiter network. You will also need to ensure that the applications
support claims-based authentication using ADFS. After you document
business requirements, you can begin designing your deployment. Figure 1
depicts an ADFS deployment with an application installed in the
perimeter network. ADFS in this design is providing SSO for corporate
users with existing user accounts in an internal AD forest.
ADFS has several prerequisites that must be met prior to deployment. The prerequisites are:
-
PKI—ADFS requires certificates to secure
communications between two environments. Self-signed certificates can
be used for testing and lab purposes but should not be used in
production deployments.
-
Windows Server 2008 R2 Enterprise—ADFS servers require Windows Server 2008 R2 Enterprise edition or greater.
-
AD Domains—ADFS requires that an AD domain exists on both the account and resource side.
-
FS Web Agent installed on application
server—The Web server hosting the application will need the federation
services Web agent installed.
Other factors that you must consider as part of your planning process are:
-
Are there redundancy and high availability requirements?
-
Will the ADFS deployment involve several AD domains?
-
Do you have a PKI deployed to support certificate requirements of ADFS?
-
Who will manage access using ADFS?
Be sure that you can answer the
aforementioned questions as part of your design and planning process.
