FICAM Architecture

Introduction

FICAM is the federal government’s implementation of Identity, Credential, and Access Management (ICAM).

ICAM is the set of tools, policies, and systems that an agency uses to enable the right individual to access the right resource, at the right time, for the right reason in support of federal business objectives.

This version of the FICAM Architecture encompasses the enterprise ICAM policies, technologies, and system approaches for government employees, contractors, and authorized partners. Citizen interactions with the federal government - or consumer ICAM - are not covered under this version of the FICAM Architecture.

The following diagram is a high-level view of the ICAM practice areas and supporting elements.

The FICAM Architecture includes government-wide enterprise architecture views with the flexibility to support each agency’s unique business or mission needs. Use the FICAM Architecture as a tool to continuously improve upon your agency’s approach and align with federal security and privacy initiatives.

Copy the graphics and text throughout this playbook to use at your agency to drive ICAM awareness, strategy developments, and communications.

What Is ICAM?

ICAM is the set of tools, policies, and systems that an agency uses to enable the right individual to access the right resource at the right time for the right reason in support of federal business objectives.

Agencies implement ICAM services and solutions to unify their IT services, improve physical access control, and improve information security and decisions. Understanding the building blocks of ICAM is key to understanding the FICAM Architecture. ICAM has three practice areas and two supporting elements. The supporting elements enhance the capabilities of the practice areas.

ICAM Practice Areas
	Identity Management is how an agency collects, verifies, and manages attributes to establish and maintain enterprise identities for employees and contractors.
	Credential Management is how an agency issues, manages, and revokes credentials bound to enterprise identities.
	Access Management is how an agency authenticates enterprise identities and authorizes appropriate access to protected services.
ICAM Supporting Elements
	Federation is the technology, policies, standards, and processes that allow an agency to accept digital identities, attributes, and credentials managed by other agencies.
	Governance is the set of practices and systems that guide ICAM functions, activities, and outcomes.

What Is the FICAM Architecture?

FICAM is the federal government’s enterprise approach to design, plan, and execute common ICAM processes.

The FICAM Architecture is a framework for an agency to use in the ICAM program and solution roadmap planning. The FICAM Architecture focuses on enterprise identity processes, practices, policies, and information security disciplines.

A federal enterprise identity is the unique representation of an employee, contractor, or enterprise user, which could be a mission, business partner, or even a device or technology managed by a Federal agency to achieve its mission and business goals (OMB Memorandum 19-17).

Who Is the FICAM Architecture for?

The FICAM Architecture is for agency personnel. An enterprise architecture is primarily used by:

• Senior Federal IT and Agency Stakeholders to understand the concepts for identity and access management services and the basic use cases supporting business objectives.
• Program Managers to find common definitions and frameworks for use in planning.
• Enterprise and Application Architects to use a common framework for designing and governing IT systems, applications, and implementations.

There are four main government-wide initiatives to help agencies implement and manage an Agency ICAM program and technology.

1. Planning and Configuration Guidance The FICAM Architecture and accompanying playbooks provide an overall guide for meeting federal ICAM requirements in an efficient and secure way. It focuses on enterprise identity processes, practices, policies, and information security disciplines. Playbooks offer stakeholders overarching strategies and tactical approaches for implementing technical FICAM topics.
2. Interagency Forum and Subcommittee: The Federal Chief Information Security Officer (CISO) Council is a primary resource for identity management, secure access, authentication, authorization, credentials, privileges, and access lifecycle management. The ICAM Subcommittee aligns identity management activities of the federal government and supports collaborative government-wide efforts.
3. Approved Products Lists (APL): The Federal Information Processing Standard 201 (FIPS 201) Evaluation Program not only tests commercial products for use in Personal Identity Verification (PIV) credentialing systems, physical access control systems (PACS), and public key infrastructures but also publish APLs. Federal acquisition professionals rely on these APLs to purchase commercial products that fully comply with federal ICAM mandates.
4. Federal Public Key Infrastructure (PKI): The Federal PKI is a network of certification authorities (CAs) that issue PIV credentials and person identity certificates; PIV-Interoperable credentials and person identity certificates; and other person identity certificates. CA-issued digital certificates, which employ cryptography, close security gaps in user identification and authentication, encryption of sensitive data, and data integrity.

What Is the History of the FICAM Architecture?

The FICAM Architecture was created in 2009 to provide a common ICAM segment architecture for federal agencies. The FICAM Architecture was the primary foundation of what later became the FICAM Roadmap and Implementation Plan, enhanced with complementary implementation sections.

In 2015, ICAM experts from across the federal government collaborated on an updated FICAM Architecture. This update was intended to be more concise, easy to understand, and visually appealing while reflecting the latest updates in cybersecurity, enterprise architecture, and ICAM policy and technology.

This site contains the current version of the FICAM Architecture. The FICAM Roadmap and Implementation Guidance v2.0 is superseded by both the FICAM Architecture updates and other complementary modernized playbooks developed by ICAM committees across government.

Goals and Objectives

The Goals and Objectives identify the aims and outcomes of a federal agency enterprise ICAM program. The goals and objectives align with ICAM functions and map to government-wide policies, cross-agency priorities, and strategic government initiatives.

Goals are aspirational statements designed for senior government leaders, agency executives, and agency ICAM program leadership responsible for setting program strategy. Objectives are action areas where agency execution strategies, action plans, and performance metrics can be developed based on alignment with mission needs.

The visual below presents the three goals, each with its own objectives.

Goal 1: Modernize security policies and solutions to make risk-based decisions, automate identity and access management processes, and move access protections closer to government data.

• 1.1 Review, update, and maintain comprehensive ICAM policies and technology solution roadmaps to inform and enforce enterprise strategic planning, risk management, and modernization.
• 1.2 Adopt and use cloud-ready systems that provide an efficient and secure way to access resources.
• 1.3 Monitor and respond to user behavior and events by using data as a strategic asset to make adaptive and risk-based decisions.

Goal 2: Enable missions to efficiently deliver services to federal and contractor employees and resources.

• 2.1 Establish and manage identities for all enterprise users and resources.
• 2.2 Design enterprise solutions to manage access to information and resources.
• 2.3 Use enterprise identity information discovery and enterprise centralized access management.
• 2.4 Leverage federated solutions to accept identity and authentication assertions made by other agency and mission partners when efficient.

Goal 3: Provide enterprise-level solutions within agencies to improve operations and promote cost-effective and efficient use of resources.

• 3.1 Streamline ICAM governance and program management within each agency to optimize execution, ensure consistency, and align intent across the enterprise.
• 3.2 Evaluate, rationalize, and migrate to modern, cloud-smart solutions for ICAM services.
• 3.3 Promote interoperability and efficiency across the federal government by buying and building ICAM solutions that use open, commercially adopted standards.

Services Framework and Service Descriptions

The Services Framework is a tool designed for ICAM program managers and information technology enterprise architects. It identifies the services that provide functionality within the scope of ICAM and assists in distinguishing between business requirements and technical solutions. The services framework includes the five practice areas and services within.

Practice Area Visual

The graphic below illustrates the five ICAM practice areas and provides a list of services that fall within each area.

Identity Management

Identity Management is how an agency collects, verifies, and manages attributes and entitlements to establish and maintain enterprise identities for federal government employees, contractors, and authorized mission partners. This service does not apply to public or consumer identity management.

An enterprise identity record is the set of attributes or characteristics that describes a person within a given context:

• Your identity within your agency’s Human Resources (HR) system is different from your personal identity at your bank.
• A person’s identity as a government contractor is different from their identity as an Army Reservist.

Although your identity remains the same over time, it evolves as your attributes change, such as when you get a promotion, change your name, receive additional training, or retire.

Agencies should manage identity attributes as centrally as possible and distribute them as needed. Examples of identity attributes include:

• Core identity attributes - First name, last name, and address of record.
• Contact attributes - Physical location, government phone number, and government email address.
• Authorization attributes - Clearance, training, and job codes.

An entitlement is a specific type of authorization attribute that refers to an application permission. Entitlements management is the act of managing those permissions. An agency may group multiple entitlements into a specific role or group to streamline provision and de-provision activities as well as for auditing and reporting purposes. For example, a new employee may require access to ten core enterprise applications on the first day of work. An agency can create a new employee group with new employee entitlements and automate the provisioning of the ten core applications rather than treat them as individual access requests. Attributes and entitlements are created or aggregated through a number of manual and automated mechanisms. Mechanisms may include:

Attributes and entitlements are created or aggregated through a number of manual and automated mechanisms. Mechanisms may include:

• Use a single sign-on tool to aggregate application access entitlements.
• Allow employees to update contact attributes in an employee record.
• Automate integration between a training system and an identity governance and administration tool to create and update annual security training.

Identity proofing is how an agency verifies an enterprise’s identity. The complexity of this process depends on the Identity Assurance Level (IAL) required for an identity. Federal agencies require a minimum IAL3 for employees and contractors. For example, a federal employee or contractor presents identity attributes via a driver’s license or utility bill. The agency verifies the identity documents and the individual’s photo (biometric).

An identifier is a unique attribute used to locate an identity in a system:

• While your agency may issue Personal Identification Verification (PIV) cards to multiple people named John Smith, each individual has a different PIV card number.
• While your agency may have more than one employee named Jane Smith, each employee has a unique email address tied only to their identity.

The Identity Management services in the Federal ICAM architecture include Creation, Identity Proofing, Provisioning, Maintenance, Identity Aggregation, and Deactivation. These services are sometimes collectively known as Identity Lifecycle Management.

Credential Management

Credential Management is how an agency issues, manages, and revokes credentials bound to enterprise identities.

A credential is a data structure that authoritatively binds an authenticator to an existing identity using one or more identifiers.

Types of authenticators include:

• Something you know, like a password or PIN.
• Something you have, like a private key or One-Time Password (OTP) generator.
• Something you are, like a fingerprint or an iris.

The Authenticator Assurance Level (AAL) determines the authenticators associated with a credential. Federal government-wide policy requires a minimum AAL2 for employees and contractors.

Examples of credentials include:

• An agency-issued smart card, such as a PIV or Common Access Card (CAC), that includes a picture and cryptographic key pairs to assert your identity at a federal facility.
• A combination of credentials, such as a username/password with an OTP generated by a mobile application, to assert your identity to a federal web application.

Unlike identities, credentials can expire. If an enterprise identity continues past a credential’s expiration date, the issuing agency can issue a new credential.

The Credential Management services in the FICAM architecture include Sponsorship, Registration, Generation & Issuance, Maintenance, and Revocation.

Access Management

Access Management is how an agency authenticates enterprise identities and authorizes appropriate access to protected services.

Policy administration is a combination of laws, regulations, rules, and agency policies that secures access to agency services. Your agency determines the requirements for an individual to access each resource category; they can be as simple or as complex as needed.

Examples of access requirements include:

• “Grant access to anyone on this list of people.”
• “Grant access to any agency employee or contractor with an authenticated PIV card.”
• “Grant access to anyone who is a federal employee, GS-12 or higher, cleared Top Secret, trained in first aid, and certified as a project manager.”

In providing access services, it can be challenging to conduct an application discovery and inventory for both physical and logical access. For logical access, see the Application Inventory and Identity Risk Analysis section of the Enterprise Single Sign-On Playbook.

Authentication

Authentication is how you verify the claimed identity of someone trying to access an agency resource. Typically, you’ll verify an identity using an authenticator associated with a credential. To determine the appropriate authenticator level, use the Digital Identity Risk Assessment Playbook

Authentication is generally a two-step process:

Step 1. Authenticate the credential:

• Did a trusted organization issue the credential?
• Has the credential expired?
• Has the credential been revoked, voided, or tampered with?

Step 2. Ensure the individual to whom the credential was issued is the same individual presenting it:

• Do the photo and attributes on the credential match the person who presented it?
• Does the person know the PIN for the credential?
• Does the person have the private key on the smart card for the certificate presented to a website?

Authorization

Authorization is how you decide whether you should allow someone to access an agency resource. Access requirements usually dictate whether you’ll allow someone to:

• Read or modify a certain document.
• Access an agency website.
• Enter an agency facility or location.

Usually, authorization occurs immediately after authentication. When you log in to a service, you present your credentials. The service then confirms that your credentials are valid (authentication) and grants or denies you access based on your assigned permissions (authorization).

Authorizations are based on progressive, fine-grained access models. Most agencies implement role-based access and move toward more fine-grained access, such as attribute-based or risk-adaptive access control, as outlined in the Federal Zero Trust Strategy. While there are defined access models, vendors may implement them in different or overlapping ways. Ensure your agency develops use cases and understands how a vendor meets the use case.

Each authorization model has benefits and limitations. The policies and access requirements defined by agency business owners help define the model that best suits their needs. More robust access control models, such as ABAC, can help agencies with improved automation, and they are increasingly adopted by cloud-native and cloud-friendly services.

The Access Management services in the FICAM architecture include Policy Administration, Authentication, Authorization, and Privileged Access Management.

Federation

Federation is the technology, policies, standards, and processes that allow an agency to accept digital identities, attributes, and credentials managed by other agencies.

Federation has many different applications, including:

• Accepting an authentication transaction from another organization:

Agency A authenticates one of its users and passes identity attributes and transaction details to Agency B. Agency B grants access to an application for that identity.

• Accepting specific characteristics (i.e., attributes such as identifiers) describing an individual from another organization:

An individual can use their agency-issued credential containing an internal identifier(s) to directly log in to a different agency’s online service. The online service registers the identifier(s) in its system for future use.

The Federation services in the FICAM architecture include Policy Alignment, Authentication Broker, and Attribute Exchange.

Governance

Governance is the set of practices and systems that guide ICAM functions, activities, and outcomes.

To perform effective governance, agencies must collect and analyze data about ICAM functions from many sources, such as policies and entitlements stores. Proper data analytics help agencies monitor compliance with established information security policies.

If your agency identifies problems during data collection and analysis, you should remediate these issues as quickly as possible. Real-time monitoring and risk mitigation are crucial to ensure employees and contractors have only the appropriate access, following the principle of least privilege.

The Governance services in the FICAM architecture include Identity Governance, Analytics, and Mitigation.

Use Cases

These use cases are designed for ICAM Enterprise Architects and business owners and describe some of the most common ICAM business processes.

Each use case includes a high-level summary of the scenario, individuals and systems involved in the use case, illustrations that show the required steps to achieve the end goal, and an icon that indicates the practice area and the service with which the use case most closely aligns.

For details about ICAM services, see the Services Framework.

While each use case describes a particular ICAM business process, the use cases are all interrelated. The use cases generalize the activities and technologies to make sure they apply across many agencies.

You can combine or build upon the ICAM use cases to support your agency’s scenarios and needs.

• +
• -

Use Case 1. Create and Maintain an Identity

When you onboard an employee or contractor at your agency, you collect identity information from the individual and store parts of that information as identity attributes. These attributes serve as a digital proxy for the individual’s identity, also known as an enterprise identity.

---

Use Case

In this use case, an administrator needs to collect or manage identity data for an employee or contractor for the purpose of creating an enterprise identity record and maintaining it throughout its lifecycle.

1. Collect information	The administrator collects identity information from the employee or contractor. This identity information may come from the individual, onboarding documents, or HR systems.
2. Create an enterprise identity	The administrator adds the identity information to the authoritative source, a data repository. Result: An enterprise identity in the authoritative source for the employee or contractor.
3. Maintain the enterprise identity	The following steps describe identity maintenance your agency should perform on a regular basis.
3a. Identify and aggregate identity data	Query your data repositories for any existing identities for an individual. Aggregate these attributes as a single enterprise identity for the individual.
3b. Update the enterprise identity	If an individual has updated personal information, there are two ways to update the enterprise identity: The administrator updates the individual’s enterprise identity attributes directly in the authoritative sources. The individual uses an agency application to update their personal information, and the application updates the individual’s enterprise identity attributes in the authoritative sources.
3c. Delete the enterprise identity	When you need to delete an enterprise identity, delete the identity attributes in the authoritative source.

---

Example

I want to create a new enterprise identity so that an individual may be established as a federal employee or contractor that will need to be identity proofed, credentialed, and granted access to agency services.

Use Case 2. Proof an Identity

Before you can create a credential and assign it to an individual, that person must provide proof of their claimed identity. Identity proofing is the process by which a federal agency collects and verifies information about a person to establish an enterprise identity.

The location or information that a person needs to access informs the Identity Assurance Level (IAL), which determines the elements you should require from that person for identity proofing. There are three IALs; however, federal agencies require a minimum of IAL2 for employees or contractors with recurring access to government resources, so these use cases do not include IAL1.

This use case describes the high-level steps to proof an identity at IAL2 or IAL3. Depending on the required IAL, you may require increasingly more information from an employee or contractor or partner along with additional verification steps. The information provided by the employee or contractor is also known as identity evidence. Identity evidence may be physical, such as passports, driver’s licenses, and birth certificates.

• IAL2 - first and last name, email address, and address of record, supported by appropriate identity documentation and verified as strong.
• IAL3 - first and last name, email address, address of record, and fingerprints, supported by appropriate identity documentation and verified as superior.

For more information about identity proofing and IALs, see NIST SP 800-63A (Section 2.2).

---

Use Case

In this use case, an administrator needs to collect or manage identity data for an employee or contractor for the purpose of creating an enterprise identity record and maintaining it throughout its lifecycle.

1. Collect identity information	IAL2 (In-person or remote) - The employee or contractor presents identity information, like first name, last name, and address of record. IAL3 (In-person or supervised remote) - The employee or contractor presents identity information, like first name, last name, and address of record, and biometric data like fingerprints.
2. Verify the identity information	IAL2 - The administrator confirms the information provided is valid and current by comparing photo identification to the individual, or confirming contact information, ensuring it matches the provided documentation. IAL3 - The administrator verifies all information with the issuing organization. Result: The individual’s identity has been successfully proofed at IAL2, or IAL3.

---

Examples

• I want to proof the identity of an employee or contractor to verify that the individual is who she says she is so that she can be issued a unique enterprise credential.
• A prospective employee or contractor has filled out their information in an HR system and requires IAL3 proofing and minimum background investigations. The prospective employee/contractor is then scheduled for in-person proofing. The prospective employee/contractor brings required identity documentation; the information is verified using approved documentation and biometrics are captured.

Use Case 3. Manage the Entitlements Lifecycle

You can assign access entitlements to individuals, roles, and groups. These entitlements define an employee or contractor’s access to agency services, so you’ll need to assign entitlements before an employee or contractor can access an agency service.

---

Use Case

In this use case, an administrator needs to assign entitlements to an employee or contractor.

1. Initiate the request	An individual requests entitlements, or joins a team with specific access requirements. The requestor may be the employee or contractor, their supervisor, HR, or a security team member.
2. Review the request	The administrator compares the employee or contractor’s requested entitlements with the relevant access requirements. If the employee or contractor qualifies for the requested entitlements and has a mission need for access, the administrator approves the request.
3. Assign the entitlements	The administrator assigns the entitlements to the employee or contractor. Any time the employee or contractor’s role or relationship changes, the administrator updates the entitlements accordingly, including removing entitlements as needed.

---

Examples

• I want to indicate that an employee or contractor requires and is allowed access to an agency service so that they can access the service when needed.
• An employee is hired to be part of the financial review team and requires access to financial applications. The employee has a role assigned to their enterprise identity record and associated with their identity attributes.

Use Case 4. Create and Issue a Credential

After you identity proof an individual, you’ll issue some proof of that individual’s claimed identity. A credential (like a physical card) is a type of authenticator that serves as a tool for an employee or contractor to gain access to agency services.

---

Use Case

In this use case, an administrator needs to issue a credential to an employee or contractor.

Note: The preferred credential for employees and contractors is a PIV card. For cases where you cannot issue a PIV card, you must use a combination of factors to reach at least an Authenticator Assurance Level 2 (AAL2) credential.

For more information about authentication and AALs, see NIST SP 800-63B (Section 4).

1. Initiate the request	An individual presents a valid government issued ID.
2. Review the request	The government ID is verified with the organization that issued it.
3. Generate and assign the authenticator(s)	Generate and assign the authenticator to the individual.

---

Example

I want to issue an enterprise credential, unique to an employee or contractor, so that they are able to access federal buildings and protected resources to which they require access.

Use Case 5. Issue a Derived Credential

A derived credential is a credential derived from an existing credential, with a different form factor, such as a credential on a mobile device. Derived credentials have the same IAL as the existing credential and the same or lower AAL.

When an employee or contractor requires authentication but cannot leverage an existing credential, they can use a derived credential. To be eligible for a derived credential, the employee or contractor must already have a valid credential with Authenticator Assurance Level (AAL) 2 or 3.

---

Use Case

In this use case, an employee or contractor interacts with the agency services to register or request a derived credential.

1. Initiate the request	A request for identity data is initiated to the identity manager. This identity manager could be a person or system, depending on the organization.
2. Authenticate the existing credential	The identity manager identifies relevant sources of data on the individual. Sources could include HR systems, security data, and personal databases.
3. Generate the derived credential	Generate the derived authenticator and note the change in the user's enterprise identity record.

---

Examples

• I want to provide an employee or contractor, who has already been issued an enterprise credential, a derived credential so that they can authenticate to enterprise applications.
• An employee or contractor travels quite a bit as part of their job. Accordingly, they are frequently limited to using a small tablet or their phone to stay connected while on the go. In this case, a derived credential is needed for purposes such as accessing secure agency websites or an agency VPN from their mobile device.

Use Case 6: Manage the Credential Lifecycle

Active credentials require regular maintenance. This use case describes the most common credential maintenance activities:

• Reset a credential - An employee or contractor forgets the password or PIN associated with a credential and requests a reset.
• Renew a credential - An employee or contractor’s credential is expiring or their identity information changes, so they request a replacement credential. You must renew a credential prior to the expiration date; otherwise, the employee or contractor must go through the issuance process again.
• Revoke a credential - An employee or contractor is no longer eligible for their credential (like separating from the issuing agency). The sponsor, supervisor, or administrator requests a revocation of all associated credentials and enterprise accounts.

You should periodically review your employee or contractors’ eligibility for credentials to identify potential orphaned data.

---

Use Cases

Reset a Credential

In this use case, an administrator needs to reset a password or PIN for an employee or contractor credential.

1. Initiate the request	An employee or contractor forgets their password or PIN, and requests a reset. If the request is valid, the identity management system approves the request.
2. Issue a reset	The system issues a password/PIN reset, which may be a temporary password or a link to a web-based reset form.
3. Reset the credential	The employee or contractor resets their password or PIN.

Renew a Credential

In this use case, an administrator needs to issue a new credential to replace one that will expire soon or has outdated identity information.

1. Initiate the request	An individual requests a renewal for an employee or contractor’s credential. This individual may be the employee or contractor, their supervisor, or an administrator with approval authority. This could also be an automated process triggered by schedules or specific events.
2. Review the request	The identity management system reviews the request and verifies that the employee or contractor qualifies for a renewed credential. If so, approve the request.
3. Replace the credential	The system issues a new credential to the employee or contractor, and updates the associated enterprise identity record.

Revoke a Credential

In this use case, an administrator needs to revoke an active credential.

1. Initiate the request	An individual sends a separation notification or a notice of a lost or compromised credential, requesting revocation. This individual may be the employee or contractor, their supervisor, HR, or a security team member.
2. Disable the credential	The administrator invalidates the credential. Depending on your agency, an individual or a system may perform this task.
3. Return the credential	If the revoked credential is physical or hardware-based, the administrator returns the credential to the appropriate individual. This individual may be a supervisor, HR, or security team member.

---

Examples

• An employee or contractor may have attempted to use a credential and input the PIN information incorrectly several times up to an agency-defined limit and has locked their account or credential. The employee or contractor requests a PIN reset. The employee or contractor is directed to an unlock service; has to verify information again to prove they are the same person issued the original credential; and follows prompts to unlock their credential, generating a new PIN in the process.
• Reset - I want to verify the identity of an employee or contractor that has already been issued a credential and reset their PIN or password so that they can continue to access enterprise resources.
• Renew - I want to verify the identity and eligibility of an employee or contractor, who has a previously issued credential that is near expiration, so that they may be issued a new enterprise credential to maintain their ability to access enterprise resources.
• Revoke - I want to remove access to enterprise resources for an employee or contractor so that they can no longer use the protected resource.

Use Case 7. Grant Access

This use case describes the steps to authenticate individuals and authorize access to agency services. Agency services can be anything from applications and files to physical facilities.

---

Use Case

In this use case, an Access Control System (ACS) Administrator needs to grant access to an employee or contractor who has an enterprise identity and active credential and needs to access a logical or physical resource. These steps assume the employee or contractor already has credentials to support authentication as well as the access entitlements to support authorization decisions.

• Authentication - I want to verify the claimed unique identity of a given employee or contractor so that the system can verify the right individual is attempting to access an agency service.
• Authorization - I want to allow access for only employees and contractors that meet established requirements so that only the people who should have access do have access.

1. Access Attempt	An employee or contractor attempts to access an agency service.
2. Authenticate the employee or contractor	The employee or contractor presents an authenticator to the ACS that meets the protected resource’s minimum assurance requirements: AAL2 (two-factor) - Something you know + something you have, like a one-time passcode. AAL3 (two-factor + hardware) - Something you know + something you have, like a one-time passcode generated by a hardware-based authenticator; or a PIV credential. For more information about AAL values, see NIST SP 800-63B Section 5: Authenticator and Verifier Requirements.
3. Determine the access entitlements and access requirements	Upon successful authentication, the ACS identifies 1) The employee or contractor's access entitlements associated with the protected resource, and 2) The protected resource's access requirements.
4. Process the access information	The ACS compares the employee or contractor’s access entitlements to the protected resource’s access requirements to decide whether to authorize access.
5. Grant access	If the employee or contractor meets the protected resource’s access requirements, the ACS grants access to the protected resource. The ACS logs the access attempt and decision for auditing purposes.

---

Example

An employee on the financial review team attempts to access a government financial application that is secured by a single sign-on (SSO) solution. The employee clicks a link to the financial application and is redirected to the SSO portal. The employee authenticates using his/her provided credential, which the SSO determines to be valid. The SSO solution or the financial application system finds the employee’s enterprise identity account and compares the roles assigned to those allowed by the financial application. The resulting determination is that the employee has authenticated to the required assurance level and has the appropriate entitlements to access the system and is subsequently logged on.

Use Case 8. Accept Federation Assertions

Federal employees and contractors often need to access protected services managed by other federal agencies. Federation is the means by which an agency can accept authentication assertions and associated identity attributes from systems within their agency and at other agencies. This allows federal employees and contractors from across agencies to access protected resources and streamlines the user’s experience.

Agencies can pass assertions to share attributes about employees and contractors.

---

Use Case

In this use case, an employee or contractor from Agency A attempts to access a federated service at Agency B. This use case assumes the employee or contractor already has an account or entitlements to access resources at Agency B, or that they will be provisioned.

For more information about granting access to protected resources, see Use Case 7. Grant Access.

1. Request access to federated service	An Agency A employee or contractor requests access to a federated service at Agency B. The employee or contractor selects the Agency A authentication service.
2. Redirect to Agency A for authentication	The Agency B system redirects the employee or contractor to the Agency A authentication service. Agency A authenticates the employee or contractor.
3. Perform transparent transaction	Agency A passes identity attributes and transaction data to Agency B via a signed assertion.
4. Agency B grants access	Agency B consumes the assertion data, optionally correlating it with an established account or local identity and makes an access control decision. The Agency B system redirects the employee or contractor to the federated service.

---

Examples

• I want to allow other federal agencies’ employees and contractors (who meet specific requirements) to access some of my agency’s resources, which facilitates cross-government collaboration and information sharing.
• An employee or contractor from Agency A visits a shared service operated by Agency B to service all federal government users. At the homepage, the employee/contractor selects their Agency A icon and is redirected to their Agency A SSO portal. They log in using their Agency A managed credentials and are redirected back to the Agency B shared service.

Reference Example

This reference example includes sample enterprise ICAM tools (e.g., solutions, applications, and software) aligned with ICAM service areas that illustrate ICAM functionality at an agency. The reference examples are designed for enterprise architects, security engineers, and solution architects to facilitate discussions regarding the technology solutions to integrate with enterprise applications and business requirements.

The system’s components are representative examples only. Some solutions chosen by your agency may span across more than one service area.

The following figure is an example of a small selection of system components only. You can modify the graphic or incorporate it as is and target state system components for enterprise roadmap planning.

Authoritative Sources

An authoritative source is a trusted repository of identity attribute data. It’s possible to have multiple authoritative sources for attributes.

Authoritative sources systems components may include:

• Human Resource systems such as payroll, time and attendance, and benefits administration
• Agency or government-wide Learning Management Systems
• Agency or government-wide Personnel Security systems for security and suitability
• Directory services, including on-premise or cloud-based directory services
• Other external or internal sources

Identity Management Systems

Identity management systems are how an agency manages the identity lifecycle.

Identity management system components may include:

• Identity Governance and Administration tool for provisioning and workflow
• Role management or role manager applications
• Identity correlation or aggregation
• Directory management
• Virtual directories

Credential Management Systems

Credential management systems are how an agency manages an authentication token bound to an identity.

Credential management system components may include:

• PIV credential service provider solutions
• Other non-PKI credential service provider solutions
• Federated certification authorities
• Private certification authorities
• Key management services
• Enterprise certificate manager
• Multi-factor authentication managers for software and hardware tokens
• Password managers

Access Management Systems

Access management systems are how an agency leverages credentials to authenticate individuals and authorize access to protected resources.

Access management system components may include:

• Enterprise Single Sign-On (SSO) applications
• Web access management applications
• Physical or facility access control systems
• Privileged access management applications
• Access policy and access rules repositories
• Policy enforcement points
• Policy decision points
• Virtual private networks
• Cloud access security brokers
• Network access management tools

Governance Systems

Governance is the set of components to centralize management, develop insights, and assist in managing ICAM areas and services. Applications across all service areas include auditing, such as standard audit logs or configuration of auditable events. Governance includes the aggregation of individual auditing and reporting into centralized tools to perform real-time or near real-time analysis, identify anomalies, and trigger mitigations for anomalous authentication or authorization events. Tools are increasingly incorporating machine learning or adaptive algorithms.

Governance systems components may include:

• Identity Governance and Administration (IGA) solutions to perform access re-certifications
• IT Service Management (ITSM)
• Security information and event monitoring (SIEM)

Agency Endpoints

Agency endpoints are resources that an agency needs to protect, including physical and digital resources.

Agency endpoints may include:

• On-premise applications
• Cloud-based applications and platforms
• Agency private networks
• Government cloud email services
• Government facilities

Policies and Standards

See the ICAM Policy Matrix for the latest set of ICAM policies and standards.