Use Cases

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top