Identity and Access Management (IAM)

• Promote and encourage alignment to the FAS Federal Marketplace (FMP) Strategy.
• Improve Customer/User Experience to FAS customers by reducing and consolidating the number of user accounts and passwords that customers use.
• Provide a consistent experience to end users for Authentication and Authorization to FAS Applications.
• Move a step closer to Single Sign-On (SSO).
• Be a cornerstone in the long-term FAS-IT Modernization Effort.
• Support long-term migration to cloud-based applications.
• Reduce Costs in operating and maintaining multiple Identity and Access Management Solutions.
• Improve the overall security posture for Authentication and Authorization of FAS systems.

Users that interact with FAS systems generally fall into the following personas:

GSA User Persona: The GSA user persona describes users who are internal to GSA. This includes members of the acquisition workforce, staff and integrator offices, and contractor support. Internal GSA users typically leverage internal business systems and authenticate via SecureAuth but may use other forms of authentication (e.g. FAS ID) in cases where a FAS-IT system supports both internal and external users.

Other Federal Government user persona: The other Federal Government user persona represents employees of an external federal government agency. These users typically leverage FAS-IT systems to solicit and award contracts or purchase goods and services for their agency via GSA contract vehicles. Other Federal Government users typically authenticate to FAS-IT systems via FAS ID or Login.gov and leverage an HSPD-12 (PIV/CAC) smart card or other additional factor (e.g. Email, SMS, or Google Authenticator) for multi-factor authentication.

State & Local Government user persona: The State & Local Government user persona represents employees of a state or local government entity. These users typically leverage FAS-IT systems to solicit and award contracts or purchase goods and services for their government entity via GSA contract vehicles. State & Local Government users typically authenticate to FAS systems via FAS ID or Login.gov and leverage Email, SMS, or Google Authenticator for multi-factor authentication.

Vendor user persona: The Vendor user persona represents GSA’s vendor partners who sell goods and services via GSA programs. Examples of Vendor use cases on FAS-IT systems include listing product and service catalogs for sale, responding to solicitations, and paying Industrial Funding Fees. Vendor users typically authenticate to FAS systems via FAS ID or Login.gov and leverage Email, SMS, or Google Authenticator for multi-factor authentication.

Public user persona: The Public user persona represents the members of the general public who are accessing FAS-IT systems as private individuals and not through a government or vendor entity. Examples include private individuals purchasing surplus government equipment via the GSA Office of Personal Property Management. Public users typically authenticate to FAS systems via FAS ID or Login.gov and leverage Email, SMS, or Google Authenticator for multi-factor authentication.

The following IAM Solutions are currently implemented within FAS-IT:

FAS-ID (Okta): FAS-ID (Okta) serves as the primary Multi-Factor Authentication (MFA) option for external IQ system users. It provides a unified identity for buyers and vendors interacting with multiple FAS systems. FAS-ID (Okta) also administers identity proofing for FAS-IT customer system access. FAS-ID (Okta) is often leveraged as a hybrid means of authentication along with Login.gov to support the overall GSA customer base. GSA systems that utilize FAS-ID (Okta) are able to send One-time password (OTP) to users via email, SMS or VOIP. Okta supports system account authentication for the Integrated Award Environment (IAE).

SecureAuth: SecureAuth is the primary authentication mechanism for internal users within FAS-IT. It provides Multi-Factor Authentication (MFA) options to ensure identity proofing for FAS-IT customer system access. SecureAuth supports system account authentication for the majority of applications within FAS-IT.

Login.gov: Login.gov enables individuals to use one account and self-managed authentication options for secure, private access to participating government applications. Login.gov provides identity proofing services to verify a person is who they say they are before account creation. It is primarily used by external agency customers, vendors and the public. Login.gov does not support system account authentication.

Access Control

• User registration through individual applications
• Authentication through Okta, Authorization through individual apps
• Privileged application access requires ticket approved by GSA Supervisor and acknowledgement of Rules of Behavior in ServiceNow
• GSA privileged users are removed when departing GSA.

Logging

• Okta stores all log information for 90 days
• Logs offloaded to FCS Splunk instance for longer term retention

Monitoring

• Office of Acquisition IT Services (IQ) staff receive emails from Okta for rate limit violations and service incidents. In addition, monitoring for anomaly detection such as authentication events that raise alerts, anomalous and suspicious activities, correlating across applications for insider threat suspicious activities, etc. are also conducted.

Configuration Control

• Changes to the production GSA Okta Org baseline go through IQ Okta Change Control Board (CCB)

Vendor Support

• Participation in business rhythms, feedback loop for enhancement requests, etc.

Okta Org Overview

An Okta org is a root object and a container for all other Okta objects. It contains resources such as users, groups, and applications, as well as policy and configurations for the Okta environment.

1. Individual ‘Preview’ Okta Org for Development / Prototyping
• Initial Okta onboarding process involves setting up an individual preview/dev environment for an onboarding application. Once the development team is ready to proceed, Okta configuration commences. System owners will need to decide on what to include with the implementation, such as agency- and app-specific registration elements; using the default or custom Okta widget; customizing the MFA challenge flow; and specifying authentication state change error messages, among others.
2. Shared Okta Org Testing
• During this stage, Okta is onboarded into the ‘shared test org’ where developers build out a production ready application.
3. Production Readiness Checklist
• ✔ Functional test scenarios in shared test Org
• ✔ Develop security documents, conduct reviews, and obtain approvals
• ✔ Help desk scripts and manuals
• ✔ Update users about Okta feature
• ✔ Plan deployment, user migration, and backout plans
• ✔ Tickets for Okta support and API rate limit increases, as needed
• ✔ Courtesy notification to all other app teams
4. Change Control Board Request & Approval
5. Deploy
• Reference: FAS-ID Onboarding

FAS-IT manages the FAS-ID and access for 4 types of personas who wish to use GSA systems and applications:

• GSA.gov users are internal to GSA and will authenticate their identities with SecureAuth. Users in this group will include, among others, staff who list their overstock items for sale, buy products or services on the Federal Marketplace, are members of the acquisition workforce, and are GSA system business owners or GSA contractors.
• The Agency.gov persona represents employees of an external federal agency or a state & local government. Contrary to those internal to GSA, they will be logging in to FAS-IT systems using an external time-based one-time passcode (TOTP) provider like Google Authenticator to authenticate their identity. Users of this group have the same functional use cases as those internal to GSA with the exception of having responsibility and ownership over their own systems and applications.
• Commercial.com persona and its users will access FAS-IT systems as commercial users to perform a variety of functional tasks, including listing their products and services for sale or managing the FAS-ID on behalf of GSA, among others.
• The Personal.com persona represents the general public and consists of users who are accessing FAS-IT systems and applications as individuals and not through a government or commercial entity.

Leveraging FAS-ID / Okta, GSA Advantage has implemented the option for

users to authenticate with their Federal employee PIV/CAC card.

How federal employees enroll their PIV/CAC card to use with their account:
GSA Advantage PIV/CAC Implementation

1. Assignment of certificate. The federal user initiates the registration process at the Advantage site by requesting and associating a unique certificate to their PIV/CAC.
2. Assignment of an alt user name. GSA Advantage assigns the federal user an alt user name.
3. Association with the user's account. GSA Advantage sends this data to Okta which stores it with the user’s account.
4. PIV/CAC authentication.
   • A federal user’s request to authenticate by PIV/CAC is redirected to Okta.
   • Okta prompts the user for their PIV/CAC certificate and alt user name, and validates the certificate chain and alt user name.
   • Okta locates the user’s FAS ID record and returns the authenticated user to the application.

How to setup PIV/CAC authentication for your FAS System:

• Registration - Reuse GSA Advantage registration process or have users register within Advantage
• Login - Setup your site to accept PIV/CAC okta login
• Okta is working to support this natively and anticipates general availability in FY22.

PIV/CAC Reference Documents

• NIST Computer Security Resource Center, Personal Identity Verification of Federal Employees and Contractors
• FICAM Roadmap V.2.0, Chapter 8 Fully Leverage PIV and PIV-I Credentials