Implement Allowlisting Validation for RepresentativeUser

[gabezurita]

Description

ARF must introduce a validation mechanism for RepresentativeUser entities to ensure that only authorized users can access the portal. The proposed solution is to implement a pilot version of an allowlisting strategy. This strategy involves adding an enabled: bool attribute (or similar) to the RepresentativeUser model. The ARF engineers will manage this attribute via a static JSON file within the vets-API repository, providing a foundational allow listing mechanism. Additionally, exploring the development of a UI for admin-type users to manage this whitelist is recommended.

Key Discussion Points and Decisions

• ARP allowlisting Implementation: The team discussed initiating a manual allowlisting process for VA representatives within ARP. Details are here.

• Auditability Concerns: An Identity Team discussion highlighted the importance of creating a documented, operational, and auditable allowlisting process. Follow-on discussions brought up the possibility of using a checked-in file in the va.gov-team-sensitive repository, a method used successfully in the past, was also discussed.

• Flipper's Capabilities: The potential use of Flipper for provisioning individual access was considered. However, we need to dig deeper into this. Further investigation into Flipper's capabilities is required, especially regarding its audit history features outlined in the Flipper Cloud Documentation. This could offer an elegant solution for recording and tracking changes to the whitelist.

Acceptance Criteria

• [x] Explore Flipper's features for individual user provisioning and audit history to assess its suitability for this application. This may be the way to go.
• [ ] Create an ADR detailing our decision to go with Flipper Gem

[cohnjesse]

We have decided to go with Flipper feature toggles, here is a document discussing why - https://docs.google.com/document/d/11fPKXlnrnPzU9TkNxqYFJZylE_sd7MBC-M_wuwUlqUQ/edit#heading=h.9fysbe2p4bfs