83215 - Create sign_in_certificates table

[dickdavis]

Summary

This PR creates the sign_in_certificates table. Currently, certificates for SiS configurations are stored in directly within the configuration as an array.

The draft PR to create the model can be found here: #16797

Related issue(s)

https://app.zenhub.com/workspaces/identity-5f5bab705a94c9001ba33734/issues/gh/department-of-veterans-affairs/va.gov-team/83215

Testing done

Migration succeeds and creates table with specified columns.

Screenshots

Not relevant.

What areas of the site does it impact?

Sign-in Service

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

Any other fields needed?

[bosawt]

some comments on the schema, I'm really gonna have to do some research on successful polymorphic models cause I'm still not convinced they're ever a good idea

[bosawt]

Is it valuable to have any of the attribute fields other than the certificate itself? I feel like the schema shouldn't have any fields that are already available on the cert itself, otherwise there could be user error in the stored attributes versus what's actually on the cert

[dickdavis]

Having the fields stored in columns on the table allows us to leverage the ORM to query for expired, expiring, and self-signed certificates more efficiently.

The alternative would be to instantiate a 509 certificate object for every certificate stored in the table and then iterate through them to find all the certificates that match whatever criteria there are (expired, expiring, self-signed, etc.) This is the approach I used in my original PR.

I'd go so far as to say if we don't store the fields in columns, then this refactor is probably unnecessary.

[dickdavis]

🤔 I could add a validation that ensures the attributes for the certificate stored in the plaintext column matches the values in the corresponding columns for the record.

[dickdavis]

Closing this PR. May revisit this idea when we tackle the certificate management epic.