# Presentation: 113038

## e-Authentication Gateway

**November 21, 2002**
** **

## Topics

**How We Got Here**
**How the Gateway Operates**
**Interoperability**

## e-Authentication Initiative Mission

**Public Trust in the security of information exchanged over the internet plays a vital role in e-Gov transformation.  The e-Authentication Initiative makes this trust possible.**

**Notes:**
Strong Authentication Polices, Standards, and products exist in both the Federal Government and Industry Arena.  However, there currently are no polices or standards available for “less than strong” .  It is our mission to help develop, define, and procure these tools.

## e-Authentication InitiativeGoals

**To build and enable mutual trust needed to support wide-spread use of electronic interactions between the public, business, and government, and across governments**
**To minimize the burden on the public when obtaining trusted electronic services from the government, and across the governments**
**Deliver common interoperable authentication solutions, ensuring they are an appropriate match for the levels of risk and business needs of each e-Gov initiatives**

## eGov Initiatives

**Government to Government**

**Internal Effectiveness and Efficiency**

- 1.  e-Vital (business case)
- 2.  e-Grants
- 3.  Disaster Assistance
-      and Crisis Response
- 4.  Geospatial Information
-      One Stop
- 5.  Wireless Networks

- 1.  e-Training
- 2.  Recruitment One Stop
- 3.  Enterprise HR Integration
- 4. e-Travel
- 5. e-Clearance
- 6. e-Payroll
- 7. Integrated Acquisition
- 8. e-Records Management

- OPM
- OPM
- OPM
- GSA
- OPM
- OPM
- GSA
- NARA

- SSA
- HHS
- FEMA
- DOI
- Treasury

**Managing Partner**
- GSA
- Treasury
- Ed
- DOI
- Labor

**Government to Business**

- 1.  Federal Asset Sales
- 2.  Online Rulemaking
-      Management
- 3.  Simplified and Unified
-      Tax and Wage Reporting
- 4.  Consolidated Health	** **
-      Informatics (business case)
- 5.  Business Compliance 1 Stop
- 6. Int’l Trade Process Streamlining

**Managing****Partner**
- GSA
- DOT
- Treasury
- HHS
- SBA
- DOC

**Cross-cutting**: e-Authentication GSA, Enterprise Architecture OMB

**Government to Citizen**

- 1.  USA Service
- 2.  EZ Tax Filing
- 3.  Online Access for Loans
- 4.  Recreation One Stop
- 5.  Eligibility Assistance
-      Online

## How We Got Here:  Requirements Development Process

**How We Got Here:  Requirements Development Process**

- May          Present

- May          June

- August

- June          Present

- E-Authentication Gateway Requirements

- Proof of Concept

- Technical

- Policy

- Acquisition

**Notes:**
E-Authentication Initial Gateway Concepts Briefings and Papers (top level green box with green arrow pointing downward).
The following boxes are on the second level:
Vendor Technical Meetings (tan box with arrow pointing downward). Technical Exchange and Industry Day (box with arrow pointing downward),
Policy Guidance Meeting (tan box with tan arrow pointing downward), Partner Briefings (tan box with tan arrow pointing downward),
Request for Information (tan box with tan arrow pointing downward).
The following boxes are on the third level:
Technical Proof of Concept (pink box with pink arrow pointing downward), Policy (pink box with pink arrow pointing downward),
Acquisition (pink box with pink arrow pointing downward).

## How the Gateway Operates: Functionality

**How the Gateway Operates: Functionality**

**Portal**

**Browser**

**Presents eGov services available to users**
**Re-directs user to GW for authentication**

**Accepts user requests for services**
**Redirects user to GW for authentication**
**May issue and update session cookies**
**Manages AuthZ**

**AA**

**Requests validation of credentials from ECP**
**Issues and updates session cookies**

**GW**

**Issues and manages credentials**
**Responds to status / validation requests**

**ECP**

**Session management via non-persistent cookies if user permits**
**Provides interface for user credential**

**Notes:**
To be discussed only on the 18th:
DCP Becomes approved provider AuthN level(s)
AA undergoes risk analysis

## How the Prototype Gateway Operates:  Developed Testbed Environment

**Designed to support multiple architectural solutions**
**Integrated multiple operating system platforms**
**Installed and configured multiple Commercial-of-the-Shelf (COTS) product suites**

** ****Firewall**

** ****Switch**
**24-port**

- Gateway Network

- Sparc Solaris
- Intel Linux
- Intel W2K

- AuthN mgt
- Directories

**GW1**

**GW2**

**GW3**

**GW4**

** ****Web Portal**

**Agency #1**

**Agency #2**

**Agency #3**

**Agency X**

**PKI ECP**

**Non-PKI ECP**

**Backup**

**End User **

- Simulated External Network

- Sparc Solaris
- Intel Linux
- Intel W2K
- Apache
- Oracle
- IIS
- .net

- Web Portal
- Agency Apps
- ECPs
- End User

** ****To MTS TransitLAN**

**Notes:**
Diagram of 8 servers defined as GW1 (Gateway Network), GW2, GW3, and GW4. These servers are interfacing with a diagram of a 24-port Switch.
The 24-port Switch is interfacing with a diagram of a Firewall.
Simulated External Network:
Diagrams of Web Portal Servers from Agency #1, Agency #2, Agency #3, Agency X, PKI ECP, Non-PKI ECP, and Backup as well as a diagram of a laptop for the End User.

## How the Prototype Gateway Operates:  Architecture 1

**GSA ACMIS (planned)**

**Apache Web**
**Linux OS**
**GW Agent**
**Agency 1 cookie**

**FirstGov Portal**

**Win2K**
**IIS 5.0**
**GW Agent**

**gw3.eauth.gov**

**Solaris 2.8**
**GW AuthN Logic**
**iPlanet Directory**
**Gw3 cookie**

**Username/Password – OPM Employee Express **

**OpenLDAP Directory**

**Government Employee Users**

**https**

**http**

**https**

**SAML**

**LDAP**

**SAML**

**VA (planned)**

**Win2K**
**IIS 5.0**
**GW Agent**
**Agency 2 cookie**

**Notes:**
Browser accepts non-persistent cookies
GW 
Holds resource protection rules for AAs
Holds either authN or authN + authZ policies
May be load-balanced, redundant, geographically replicated
Knows which ECPs are acceptable for AAs
Agency App Web Server
Reads protection rules from GW
IS ISAPI,NSAPI module, intercepting resource request before access
Gateway product suite specific
ECP
Purpose is to answer validation questions about users’ credentials
May return user information based on GW policies

## How the Prototype Gateway Operates:  Architecture 2

**USDA-NFC**
**Reporting Center**

**Win2K**
**IIS 5.0**
**GW Agent**

**USDA-NFC**
**Web Star**

**Win2K**
**IIS 5.0**
**GW Agent**

**FirstGov Portal**

**Win2K**
**IIS 5.0**
**GW Agent**

**gw-4.eauth.gov**

**gw-4p.gov**

**Win2K**
**IIS 5.0**
**GW AuthN Logic**
**gw-4p cookies**

**gw-4g.gov**

**Win2K**
**IIS 5.0**
**Pin/Password Server**
**AuthZ Logic**

**gw-4g.gov**

**Win2K**
**IIS 5.0**
**PKI Server**

**USDA-NFC Pin/Password DB**

**Win2K**
**Oracle 8.1.7 **

**Entrust PKI**

**Win2K**
**X500 Directory**

**Government Employee Users**

**https**

**http**

**https**

**https**

**Corba SSL**

**LDAP**

**firewall**

**Notes:**
The FirstGov Portal , the USDA-NFC Reporting Center, the USDA-NFC Pin/Password DB, the gw-4.eauth.gov, and the Entrust PKI has clip art of 2 file servers.
The Government Employee Users has clip art of two PCs.

## How the Prototype Gateway Operates:  Process Flow

- User Selects App

**Notes:**
The “User Selects App” is depicted by clip art of a laptop.

## Demo begins here

## Interoperability Interfaces – General Agency Application Overview

**A web server is protected by installing a vendor-specific ISAPI, NSAPI, or Apache module plug-in**
**When the web server starts (or is restarted) it reads the resource protection policies from a remote policy store (LDAP directory) located at the e-Authentication gateway**
**Using this method, code does NOT have to be integrated into each web page being protected **

**Agency**
** ****Web Server**

**Win2K**
**IIS 5.0**

**Gateway COTS **
**Product Suite**

**Solaris 2.8**
**iPlanet LDAP**
** ****Directory**
**GW AuthN Logic**

**GW Agent **
**(Enforcer)**

**Application Policy Store**

**GW Policy Store**

**Interface from GW web agent to backend business process is customized per application**

**Other Agency Applications**

**Application Access Control Policies**

**Interface to GW is customized per application**

**Notes:**
The Gateway COTS Product Suite, the Agency Web Server, and the Other Agency Applications uses clip art of two file servers.

## Process for E-Gov Initiative Integration

**Programmatic**
**Determine identity authentication requirements**
**Risk assessment tools available**
**Determine resource protection policies for authorization management**
**Technical**
**Meet with gateway development team to identify unique interoperability requirements**
**Determine integration requirements to complete interface from gateway AA agent to backend business processes**
**Complete integration testing with gateway development testbed**
**Integrate with “on-line” gateway pilot following successful testing**

## Interoperability Interfaces – ECP

**PIN/Password ECP**

**Gateway COTS **
**Product Suite**

**Solaris 2.8**
**iPlanet LDAP**
** ****Directory**
**GW AuthN Logic**

**GW Policy Store**

**User’s login name is used to determine the full DN to their record**
**A “bind” is attempted to the directory using the supplied password**
**Results of “bind” attempt determines the validation status**

**PKI ECP**

**LDAP**

**LDAP Directory**

**LDAP, OCSP, ...**

**GW supports validation protocols (e.g., LDAP, OCSP) as defined by the ECP**

**Notes:**
The Gateway COTS Product Suite, the PIN/Password ECP, and the PKI ECP has a picture of 2 file servers.

## ECP Integration

**Current Candidate ECPs**
**Internal Government potential ECPs:  USDA-NFC, ACES, Treasury-Pay.Gov, Treasury, DoD, NASA, OPM-Employee Express, USDA- WebCAAF**
**External Government potential ECPs:  State issued credentials (e.g., Illinois), universities, banking industry, healthcare**
**Technical process**
**Determine ECP defined protocols for validation**
**Meet with gateway development team to identify unique interoperability requirements**
**Complete integration testing with gateway development testbed**
**Integrate with “on-line” gateway pilot following successful testing**

## The Challenge to Interoperability

**The Challenge to Interoperability**

- E-Authentication

## Achieving Interoperability:  Applications and Electronic Credential Providers (ECPs)

**Applications**
**Determine authentication requirements**
**Configure web server technical interoperability with gateway**
**Configure interface to backend business process**

**ECPs**
**Determine validation protocol requirements**
**Username/password**
**PKI**
**Configure technical interoperability with gateway**

## Backup Slides

## Interoperability Interfaces – AA Web Server

**Known good configurations**
**Win2K w/ SP2, running IIS 5.0**
**Sun's JRE v1.3.1_02 is also needed if **
**SAML support is desired, or**
**An EJB application server, JSP servlet engine/container (web service) is being protected**
**Typically do NOT want Sun's standalone J2EE (containing Sun's standalone JVM); instead, want Sun's J2SE**
**All products reported support for configurations on SPARC boxes (but none have been successfully tested to date)**

## Interoperability Interfaces – ECP

**PIN & Password**
**User's login name is used to determine the full DN to their record**
**A "bind" is attempted to the directory using the supplied password**
**Resulting pass/fail status of that bind attempt determines the status of the supplied password**
**iPlanet LDAP directory generally supported**
**OpenLDAP supported by at least one product**
**Users should be installed in a general, well-known directory schema**
**PKI-based**
**Most products assume a client-side SSL certificate is being used for user identification**
**Web servers typically complete SSL tunnel setups before the ISAPI, NSAPI, or Apache module (which protects the web resources) is called**
**Generally assumed that the target web site validates the certificate before the gateway-specific enforcer is called**
**At least one product incorporates certificate validation without customization**
**GW supports validation protocols (e.g., LDAP, OCSP) defined by the ECP**