Platform and Infrastructure

Contoso evaluated several vendor platforms for identity and access management, including Microsoft. Based on the company's requirements, Contoso has chosen to standardize on the Microsoft Identity and Access Management platform. This chapter discusses the infrastructure design that resulted from this decision.

On This Page

	Solution Concept
	Solution Architecture
	Enabled Solution Scenarios

Solution Concept

The key capabilities Contoso requires are provided by the following features of the Microsoft Identity and Access Management platform:

Top of page

Solution Architecture

The solution architecture includes the following components:

Directory Services

Successful operation of the Contoso identity and access management platform requires the Contoso team to identify the authoritative source for creating identity information, and an authoritative location for storing application and identity information. The team also needs to implement a suitable attribute information flow between directories.

The organization's current directory services configuration for its infrastructure includes the following:

The extranet Active Directory forest cannot be used as the authoritative directory service, because it only contains shadow accounts for employees. The Sun One Directory Server 5.1 is scheduled for decommissioning after the application that depends on it has been rewritten to work with Active Directory.

The intranet Active Directory forest provides the current central repository for user accounts within Contoso. Therefore, the company selected the intranet Active Directory to act as the authoritative source for all directory and application-specific information.

The Contoso team will use an identity integration product to replicate certain directory objects to achieve the following:

Intranet Active Directory Forest

The intranet forest consists of an empty root domain corp.contoso.com and a single child domain na.corp.contoso.com. The na.corp.contoso.com domain contains the following organizational units (OU):

The step-by-step process for installing Active Directory on Windows Server 2003 and creating OUs is covered in the product documentation.

Extranet Active Directory Forest

The external forest contains a single domain perimeter.contoso.com. The perimeter.contoso.com domain runs at the Windows Server 2003 functional level and contains the following OUs:

There is no trust relationship between the internal and the external forest. The section on Trust later in this chapter discusses the reason for this.

Figure 4.1 shows the Active Directory structures for Contoso.

Figure 4.1. The Active Directory logical structure for Contoso

For more information about Active Directory, see the Windows Server 2003 Active Directory page.

For additional guidance, see the Designing and Deploying Directory and Security Services page.

Authentication Methods

Contoso chose authentication methods based on the characteristics of each method and the environment in which they will operate. The selection process resulted in a single authentication method for the intranet directory, and three methods for the extranet directory as shown in the following two figures.

Figure 4.2. Intranet authentication and authorization mechanisms in the Contoso infrastructure
See full-sized image

Figure 4.3. Extranet authentication and authorization mechanisms in the Contoso infrastructure

Authenticating to the Intranet Directory

The primary authentication mechanism for the internal network is the Kerberos version 5 protocol, which Windows Server 2003 and Windows XP Professional support natively. Many other platforms include Kerberos protocol libraries, especially various distributions of UNIX, including Linux. Contoso will use the Kerberos version 5 protocol wherever possible because it is a standards-based highly secure network protocol. Many platforms implement Kerberos version 5 protocol authentication, and for this reason, this protocol provides a good foundation for interoperability.

All managed client computers on the internal network, including computers running the Windows XP Professional and Sun Solaris operating systems, log on by using the Kerberos version 5 protocol to accounts in the internal forest. When they have logged on, users authenticate to specific resources, again using the Kerberos version 5 protocol.

Authenticating to the Extranet Directory

The external network uses several different types of authentication, because the Kerberos version 5 authentication protocol is not currently supported for web clients on Internet-facing applications in the Contoso environment. The three external, Internet-facing applications hosted in the Contoso perimeter network use the following distinct authentication methods:

All three of these authentication mechanisms use the extranet Active Directory forest as the identity store. The extranet domain contains user accounts with mappings for Passport and client certificate authentication, as well as secret password credentials for Windows Forms-based authentication.

Authorization Methods

The main authorization method Contoso will use employs access control lists (ACL) on file and print servers (not shown in Figure 4.3). However, Contoso will also use roles-based access control through Authorization Manager in Windows Server 2003. Authorization Manager interacts with Internet Information Services (IIS) 6.0 to provide both URL – level authorization and detailed, application-level entitlements for access to Web applications.

Contoso will use security groups to organize users, for example by department or role. These security groups will simplify the granting of entitlements to users, and reduce the administrative operations involved when users change jobs within the organization.

Trust

The Contoso team had the following set of choices to consider when implementing federation between the external directory and the internal infrastructure directory:

Cross-Forest Trusts

Windows Server 2003 enables the use of trusts between forests. In the Contoso environment, this option was considered so that employees who use the external applications could authenticate to the internal directory through the trust relationship.

The company's long-term vision is to create and deploy applications that take advantage of end-to-end authentication. A necessary task before reaching that milestone is to undertake a thorough analysis of the internal network security, and then follow up with corrective action as needed to fix any problems identified.

In the end, the Contoso team decided not to establish such a trust in the organization's environment. A combination of security concerns specific to the Contoso scenario, and the fact that the company's application scenarios do not currently require the trust relationship informed this decision. In the Contoso case, the main concern is the security of the internal network rather than additional application functionality resulting from a trust relationship between the external and internal forest.

On the other hand, your organization could have scenarios in which you need to implement cross-forest trusts. For example, external users might need to authenticate against an external server and access information inside your organization's intranet. In this case, you could require that the user identity carries across with the application request from the Web server to the application data source. Such a scenario is possible by using the new Kerberos version 5 protocol delegation features, and cross-forest trust mechanisms included with Windows Server 2003.

PKI-qualified Subordination

Public Key Infrastructure (PKI) provides an organization with the ability to exchange data securely over a public network by using public-key cryptography. A PKI consists of certification authorities (CA) that issue digital certificates, directories that store the certificates (including Active Directory in Windows 2000 Server and Windows Server 2003), and X.509 certificates that are issued to security entities on the network. The PKI provides validation of certificate-based credentials and ensures that the credentials are not revoked, corrupted, or modified.

Qualified subordination is the process of cross-certifying CA hierarchies by using basic, policy, naming, and application constraints to limit which certificates are accepted from partner CA hierarchies, or a secondary hierarchy within the same organization. You can use qualified subordination to define which certificates issued by a partner's PKI are trusted by your organization. Qualified subordination also provides methods for compartmentalizing and controlling certificate issuance within an organization according to policy guidelines.

Contoso implemented a three-tier PKI infrastructure consisting of an issuing CA, an offline intermediate authority, and an offline root CA in accordance with Microsoft best practices. Contoso IIS administrators then requested server certificates from the issuing certificate authority to enable SSL encryption on the Internet Web applications on IIS. Contoso also enabled user certificate auto-enrolment policy in Active Directory for employees, and enabled Active Directory Mapper and client certificate mapping in IIS.

For more information about cross-forest trusts and PKI-qualified subordination, see the following pages on Microsoft.com:

For more information about deploying Microsoft Certificate Services, download and review Ch. 16, "Designing a Public Key Infrastructure".

Shadow Accounts

The federation design that Contoso selected to implement authenticates internal users (employees) in the perimeter network applications by creating shadow accounts in the external Active Directory. These shadow accounts are only for certificate-based authentication. The shadow accounts contain a limited amount of authorization information relevant to the extranet application, such as name and group membership, but not the user's account password.

The Sales department employees use these shadow accounts to access an application hosted in the perimeter network. Because the shadow accounts are sufficient to access the external application, no trust is required between the external and internal forest.

Identity Life-Cycle Management

To manage the life cycle of digital identities, Contoso selected Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1). This product provides the necessary identity integration support for efficient synchronization, provisioning, and deprovisioning of digital identities. It also provides management agents that enable connections to the various identity stores within the Contoso environment.

The Contoso implementation will use Microsoft certificate services and policy configuration to enable user certificate auto-enrollment. The auto-enrollment capability makes user certificate management possible and cost-effective. In the Microsoft Identity and Access Management Framework, user authentication with client certificates is most appropriate for scenarios in which it adds an identifiable security benefit.

For example, client certificate authentication avoids the security risk associated with using passwords to authenticate to servers hosting the Sales and Contacts application in the perimeter network. Contoso only deploys certificate services and configures auto-enrollment on its internal network, as no application scenario requires certificate-based authentication for external customers and partners.

Identity-Aware Applications

To provide support for developing identity aware applications, Contoso implemented a policy of using the Kerberos version 5 authentication protocol with Active Directory domain controllers wherever possible. Applications that cannot use the Kerberos protocol for authentication (such as extranet applications) will instead use Windows Forms-based authentication for business-to-business (B2B) cases, Microsoft Passport for business-to-consumer (B2C) cases, and certificates or smart cards (in the future) for business-to-employee (B2E) cases.

Authorization will be provided by access control lists (ACL) for persistent objects, such as files and items in the directory. Web-based applications will use role-based access that uses Authorization Manager.

The Contoso Network

Figure 4.4 illustrates the full implementation of the Contoso identity and access management architecture.

Figure 4.4. The network layout of the Contoso identity and access management infrastructure
See full-sized image

The implementation for the Contoso identity and access management technology architecture includes the following:

The Contoso identity and access management platform is based on the Windows Server System Reference Architecture (WSSRA) developed by Microsoft and a number of leading hardware and software vendors. WSSRA (formerly Microsoft Systems Architecture 2.0 or MSA) provides tested step-by-step instructions for implementing large-scale IT infrastructures based on Microsoft technologies.

For more information about WSSRA, see the Windows Server System Reference Architecture page.

Appendix A to this document provides the settings to configure the Contoso environment in a Virtual PC (VPC) 2004 test environment.

Top of page

Enabled Solution Scenarios

A Microsoft platform infrastructure enables the following solutions:

The underlying strategy for the company is to replace manual and inefficient administrative processes for managing digital identities with automated and efficient ones. Later papers in this series provide much more detail on each of these targeted areas that are outlined in the following sections.

Identity Aggregation and Synchronization

To provide identity aggregation and synchronization within the organization, Contoso chose to use MIIS 2003 with SP1 as the identity integration product that will integrate with all of the company's directory services and other identity stores, including:

For more information about this topic, see the "Identity Aggregation and Synchronization" paper in this series.

Password Management

To implement effective password management, Contoso chose the following components:

For more information, see the "Password Management" paper in this series.

Intranet Access Management

For intranet access management, Contoso standardized on the following configurations:

For more information, see the "Intranet Access Management" paper in this series.

Extranet Access Management

For extranet access management, Contoso chose the following architecture to grant access to Web applications for partners, customers, and employees:

For more information, see the "Extranet Access Management" paper in this series.

Developing Identity-Aware ASP.NET Applications

To ensure consistency when developing identity-aware applications, Contoso standardized on the following approaches:

For more information, see the "Developing Identity-Aware ASP.NET Applications" paper in this series.

Top of page

4 of 9