Summary

For this we need to process the cert (logic should already be present) and pull the serial number out of it.

We should take that serial number and query the legacy_certificate table by that serial number.

• If no cert is found, error.
• If that cert is expired (based on current EST date), error.
• If the certificate is not connected to an agency, error (NOTE: this should only be the behavior for grantor endpoints)

Then for the given operation, we need to figure out which privilege a user requires which should be configured per operation.

• GetSubmissionListExpanded → legacy_agency_viewer
• GetApplication → legacy_agency_grant_retriever
• GetApplicationZip → legacy_agency_grant_retriever
• ConfirmApplicationDelivery → legacy_agency_grant_retriever
• UpdateApplicationInfo → legacy_agency_assigner

We then just need to call our RBAC code passing in the user associated with the cert, the privilege defined for the operation, and the Agency.

--
NOTE:
Some systems that parse serial numbers (like Home | Grants.gov ) seem to add leading zeroes in some cases to serial numbers. Our cert in training doesn’t start with 00 but it does in what Home | Grants.gov stored. Seems this depends on the particular system and special octet/int parsing to make it “valid”. Need to verify what the library we use to parse the cert does for these and potentially adjust it.

At the very least, openssl x509 -noout -serial -in <some_file>.crt doesn’t have the leading zeroes.

--

Acceptance criteria

• Process the cert dnd pull the serial number out of it
• Throw error If no cert is found
• Throw error if cert is expired
• Throw error if cert is not connected to agency (grantor only)
• Figure out which privilege a user requires per operation
• Calls RBAC code with the user associated with the cert, privilege for operation, and agency