eAuthentication – Technological Profile - Technical Architecture Plan
United States Department of Agriculture (USDA) eGovernment Program
Technological Profile – Technical Architecture Plan
eAuthentication Business Case
DRAFT
February 2003
USDA eGovernment Program 43
eAuthentication_TechnologicalProfile_TechnicalArchitecturePlan_v1.5.doc2
eAuthentication – Technological Profile - Technical Architecture Plan
Table of Contents
Revision History iii
Previous Change History iii
Document Sign-off iii
1 Introduction 1
2 Current Architecture 3
2.1 Authentication 3
2.2 Electronic Signature 4
2.3 Public Key Infrastructure 4
3 Architecture Drivers 5
4 Target Architecture 7
4.1 Infrastructure Components 12
4.1.1 Firewalls 12
4.1.2 IDS 13
4.1.3 Network Devices 14
4.2 Registration and Reporting DMZ 15
4.2.1 Registration Component 16
4.2.2 Report Generator Component 16
4.3 Authentication DMZ 18
4.3.1 Authenticator Component 19
4.3.2 Credential Manager Component 19
4.4 Certification DMZ 21
4.4.1 USDA Certificate Repository 22
4.5 Certification Enclave 23
4.5.1 PKI Registration Component 24
4.5.2 USDA Certification Authority (CA) Component 24
4.5.3 PKI Audit Monitor Component 24
4.5.4 PKI Management Station Component 24
4.5.5 PKI Root CA Component 25
4.6 Data Enclave 26
4.6.1 Authentication Data Store Component 27
4.6.2 Credential Store Component 28
4.6.3 Audit Log/Reporting Component 28
4.7 Management Enclave 29
4.7.1 IDS Monitor Component 30
4.7.2 Audit Monitor Component 30
4.7.3 Management Station Component 30
4.8 Policy, Procedure, and Standards Components 31
4.8.1 Authentication Mechanism Guidance 32
4.8.2 Electronic Signature Guidance 34
4.8.3 Performance Measurement 37
4.9 Intended Uses of the Architecture 38
4.10 Scope of the Architecture 39
4.11 Depth of the Architecture 39
5 Integration Approach 40
6 Enterprise Architecture Impacts 41
6.1 Relationship to Current IT Initiatives 41
7 Appendices 42
7.1 Acronyms and Abbreviations 42
7.2 Glossary 43
Revision History
Previous Change History
Table a – Previous Change History
Version / Date / Author / Comment1.0 / 12/03/2002 / Elaine K. Turville / Initial Document
1.1 / 12/09/2002 / Elaine K. Turville / Updated Naming
1.2 / 12/18/2002 / Elaine K. Turville / Updated with team comments
1.3 / 01/13/2002 / Elaine K. Turville / Updated with team comments
1.4 / 01/28/2003 / Elizabeth A. Ampagoomian / Updated team comments
1.5 / 01/28/2003 / Liesl M. Awalt / Updated team comments
Document Sign-off
Table b – Document Sign-off
Date / Name / TitleUSDA eGovernment Program 43
eAuthentication_TechnologicalProfile_TechnicalArchitecturePlan_v1.5.doc2
eAuthentication – Technological Profile - Technical Architecture Plan
1 Introduction
This Technical Architecture Plan provides a description of the components that are necessary for a successful implementation of an eAuthentication solution set. The target architecture described below provides a conceptual model of the eAuthentication solution. This model provides a high-level view of the functions required to support the eAuthentication functional requirements and to support the business needs identified during the Planning phase of the Capital Planning process. The model provided can be applied to develop an enterprise-wide eAuthentication system and to evaluate the assurance provided by existing Agency authentication mechanisms as eAuthentication candidates. In developing this architecture, the eAuthentication team analyzed business requirements imposed upon USDA by Federal law and Federal regulations, and has solicited additional input from the USDA Agencies and Staff Offices to identify high-level functional business process needs. This architecture provides the functional system mechanisms necessary to meet Federal policy and provide long-term support to current and future eGovernment initiatives in the area of authentication and electronic signature.
This document is intended to provide a strong foundation for subsequent analysis and design activities that will continue through the next phase of system development. This document is not intended to identify specific components and vendors or providers of technology hardware, software, or services. The identification of these specifics will occur within subsequent stages of the system development process.
In general, the target technical architecture details eAuthentication functions that provide support to various authentication technologies including the traditional username and password pairs, PKI certificates, smart cards, tokens, biometrics, and others. The technical architecture is intended to reuse the existing architecture, provide the capability not only to support application-level authentication requirements, and support authentication at the network and operating system level where possible. The initial implementation efforts will support a basic level of authentication for web-based applications. However, the architecture will provide the ability to grow to support additional needs in the future.
The eAuthentication target architecture also incorporates Single Sign-On capabilities that allow users to sign on once and gain access to all application resources that they have been authorized to view or change. Because authentication is integral to supporting the concept of electronic signatures, the target architecture provides capabilities that are compatible with key Federal and industry standard signature mechanisms. In order to support specific non-repudiation needs, the PKI implementation described herein will not only permit users to sign-on, but to sign documents as well.
The technical architecture described in this document is intended to be flexible, allowing new authentication technologies to be added as developed and required by USDA business need. The technical architecture is also intended to be modular and incorporate existing USDA systems. The intent is that the system will only incorporate those authentication technologies needed at any given time. As additional requirements are identified, the system can “awaken” existing capabilities that have not been required, or can add modules to incorporate new technologies. In addition, the architecture is designed to be scalable. As requirements increase, both from the increase in the number of applications integrated with the solution and from the number of users and roles that use the system, the system can grow to meet the need.
This document discusses the current architecture of authentication and electronic signatures employed within the USDA Agencies and Staff Offices, will identify architecture drivers, and will provide the target architecture and an integration approach.
2 Current Architecture
This section describes the current state of the architecture within the USDA Agencies and Staff Offices related to authentication, electronic signatures and supporting authentication infrastructures.
2.1 Authentication
Currently, the authentication environment within the USDA Agencies and Staff Offices is heterogeneous in nature. At the application level, authentication is generally performed on a system-by-system basis. Some efforts to provide authentication mechanisms that span multiple applications and multiple Agencies are in development or testing, but no integrated enterprise-wide authentication approach could be identified. Looking at authentication mechanisms outside of applications, including network and system logons, there was no standard approach to authentication. Agencies establish their own authentication mechanisms that in some cases are not compatible with authentication mechanisms employed by other Agencies. As an example, network logins within some Agencies use Microsoft Active Directory, others use Microsoft Windows NT Domain Controllers, and others use Novell Directory Service. While each performs a similar function, the manner in which they perform the function is typically not compatible with others.
One application authentication mechanism identified as a candidate for eAuthentication technology, pending certification and accreditation, is the Web Central Authentication and Authorization Facility (WebCAAF) authentication mechanism deployed by the county-based agencies. WebCAAF was initially piloted, and user access is being migrated in a phased approach. WebCAAF currently provides application authentication to 40,000 employees within the Farm Service Agency (FSA), NRCS (National Resource Conservation Service), and Rural Development (RD) as well as 2,000 external customers that have signed up to use WebCAAF to authenticate through the Internet. In addition, the WebCAAF functions have been evaluated in some manner by the Office of General Counsel (OGC) and have been determined to meet the requirements related to electronic signature.
The WebCAAF system is based on the Netegrity SiteMinder policy management software, which provides some authentication capability, coupled with session management and single-sign-on functions. The data stores used to support the SiteMinder component are the Lightweight Directory Access Protocol (LDAP)-derived Microsoft Active Directory stores. A registration component is currently under development to allow users to update profile information and to allow Agencies to manage their users. The servers that provide the authentication and data storage functions are load balanced, are configured in clustered segments, and are replicated among three sites in order to ensure redundancy and to reduce the risk of malicious or inadvertent denial of service.
2.2 Electronic Signature
Like authentication mechanisms, mechanisms for performing electronic signatures are varied. Electronic signatures currently in use include variants from accepting signed faxes and comparing signatures with signature cards to performing digital signatures. Agencies have expressed the need for digital signature capabilities, but many have not performed the analysis to determine what level of electronic signature is required for their business process. Generally, there were no systems or guidance identified that provided standard approaches to performing electronic signatures defined with specific scenarios in which those signatures would be considered appropriate.
2.3 Public Key Infrastructure
In order to support the government-to-government business needs of the Agencies, the National Finance Center (NFC) has established a Public Key Infrastructure (PKI) program that is capable of issuing digital certificates to employees that would allow those employees to generate digital signatures of documents and to authenticate themselves to an application or system. The system is currently undergoing evaluation for accreditation purposes. The software that provides the PKI function for the NFC is the enTrust suite of PKI products. The platforms used include Sun Solaris sever-class hosts and X.500 directory stores.
3 Architecture Drivers
Architecture drivers are those factors that guide the development of the architecture. Specifically, the architecture drivers include functional, technical, and performance requirements. In addition, architecture drivers include principles of system architecture, including modeling to support the enterprise architecture approach to system implementation.
The following provides a list of the high-level requirements that have been identified as sources of functional requirements related to the eAuthentication Initiative. These sources were analyzed for specific functional requirements based on the laws, regulations or policies that they define. These functional requirements were then used as high-level business requirements and were therefore incorporated into the process of defining the architecture.
· United States Department of Agriculture (USDA) eGovernment Program, eAuthentication Business Case, May 17, 2002;
· Public Law 99-508, Electronic Communications Privacy Act of 1986, October 21, 1986;
· Public Law 100-235, H.R. 145, Computer Security Act of 1987, January 8, 1988;
· Public Law 105-277, Title XVII, Government Paperwork Elimination Act (GPEA), October 21 1998;
· Public Law 106-222, Freedom to E-File Act, June 20, 2000
· Public Law 106-229, Electronic Signatures in Global & National Commerce Act, June 30, 2000;
· H.R. 3802, Electronic Freedom of Information Act Amendments of 1996, January 3, 1996;
· 5 U.S.C. § 552A, The Privacy Act of 1974;
· 29 U.S.C. § 794(d), Section 508 of the Rehabilitation Act of 1973, August 7, 1998;
· Office of Management and Budget (OMB) A-123, Management Accountability and Control, June 21, 1995;
· Office of Management and Budget (OMB) A-127, Financial Management Systems, July 23, 1993;
· Office of Management and Budget (OMB) A-130, Management of Federal Information Resources, November 28, 2000;
· Office of Management and Budget (OMB) Memo 00-10, Implementation of the Government Paperwork Elimination Act, April 25, 2000;
· National Institute of Standards and Technology (NIST) Special Publication 800-9, Good Security Practices for Electronic Commerce, Including Electronic Data Interchange, December 1993;
· National Institute of Standards and Technology (NIST) Special Publication 800-14, Guide for Developing Security Plans for Information Technology Systems, September 1996;
· National Institute of Standards and Technology (NIST) Special Publication 800-25, Federal Agency Use of Public Key Technology for Digital Signatures and Authentication, October 2000;
· National Institute of Standards and Technology (NIST) Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems, August 2001;
· Federal Information Processing Standards (FIPS) 102, Guidelines for Computer Security Certification and Accreditation, September 1983;
· National Security Telecommunications and Information Systems Security Committee (NSTISSI) 4009, National Information Systems Security (INFOSEC) Glossary, September 2000; and
· Federal Information Systems Controls Audit Manual (FISCAM), January 1999.
In addition to the functional requirements imposed by Federal Policy, requirements related to the business functions performed by the Agencies and Staff Offices were identified both as part of the eAuthentication business case and through meetings with Agency representatives to identify eAuthentication requirements. These requirements are specifically documented in the USDA eAuthentication Functional Requirements document and the USDA eAuthentication Technical Requirements document. These requirements have been incorporated into the technical architecture. The following list provides a brief overview of the requirements:
· The system is expected to support upwards of 15 million users (including 100,000 employees and an unknown breakdown of customers, citizens, business partners) at maturity;
· The system is expected to perform authentication and arbitrate trust between other USDA and Federal Agency authentication mechanisms. To date the identified mechanisms include the Federal Bridge Certification Authority (FBCA) for PKI certificates and the General Services Administration (GSA) eAuthentication program;
· The system is expected to support electronic signature and digital signature capabilities natively;
· The system is expected to maintain 24 hours a day, 7 days a week uptime with only reasonable and minimal downtime for maintenance; and
· The system is expected to be modular in approach and scalable to allow the system to start small and grow as requirements are identified.
4 Target Architecture
The target architecture describes a conceptual view of the target architecture. Each component corresponds to a component that must be implemented or acquired in order to perform the required eAuthentication functions. The architecture depicted provides a model to which systems can be developed or against which existing systems may be evaluated. The components provided are intended to describe specific technical functions while the model provides the context in which those components interact. This cooperative interaction is what allows the individual components to provide the eAuthentication function. The functions identified are not specific to any vendor product or existing system, but are components that must be represented in an eAuthentication solution to fulfill defined functional and technical requirements.