FI-2980 Release Preparation

[alisawallace]

Summary

This is the final PR prior to releasing the test kit. Updates include disabling the use of auto-generated certs and general cleanup of test inputs and descriptions.

Concerns of Note

• Tests may be run at 3 group levels which complicates inputs and descriptions
  • Current levels
    • suite level (both auth flow groups)
    • auth flow group level (test groups 1 or 2)
    • individual discovery, registration, and authentication step of each auth flow (1.1, 1.2, 1.3, etc.)
• I tried to balance providing users with enough information to use the test kit successfully and not overwhelming them, but given the inherent complexity of this IG ad number of options in it, I worry it leans towards the overwhelming side

Testing Guidance

• All spec tests are passing
• Main interest for feedback is reviewing the test kit in the web app and making sure it looks good

[Jammjammjamm]

It would be really helpful if the behavior changes were in their own PR separate from the release prep.

[alisawallace]

It would be really helpful if the behavior changes were in their own PR separate from the release prep.

Some of the behavior changes I included in the PR summary were taken care of in the last PR, so I updated the summary.
I also still have a little bit of cleanup to do (get unit tests and linter passing) before I will remove the draft status.

My understanding of this PR is that it's the catch-all for anything we need to do to clean up the test kit prior to release. This includes temporarily disabling the use of auto-generated certs. There isn't much impact to the underlying behavior of the code, since it's just removing the inclusion of the generate_certs test from test groups and commenting out a custom route that's no longer needed. Rather, the majority of the changes are to the test and input descriptions that are already getting polished and reviewed for release.

So with that said, would you still like me to break up this PR, and if so, could you clarify what counts as release prep vs needing its own PR?

[alisawallace]

@Jammjammjamm I completed the following:

• Fixed the nil safety concern in signed_metadata_contents_test.rb
• Ordered the inputs based on your TODO, which fixed the ordering problem (thank you)
• Updated the gemspec file and added the use of a version.rb file based on what was in SMART App Launch test kit - I ran the test kit from scratch, including bundle install, and everything worked on my machine
• Moved the Inferno certs to spec/fixtures (since they are only used for unit testing for the time being)
• Mocking the CRL endpoint:
  • Updated the Inferno certs to include a mock CRL endpoint
  • Created a CRL file signed by the Inferno CA
  • Updated the generate_certs.sh script to add CRL creation
  • Updated unit tests to mock the GET request for the CRL file and use Inferno certs instead of EMR Direct test certs
  • Removed the EMR Direct cert files from the test kit

I think that is everything we discussed, it's ready for re-review now - thanks!
I think this addresses everything we discussed, now ready for re-review - thanks!

[Jammjammjamm]

These files should live in lib if they're being read by a file in lib.

[alisawallace]

Thanks for the reminder, completely forgot about the default file loader module being in lib. I moved only the files being read via the module to the lib/udap_security/certs directory and kept all the other stuff pertaining to certs in the spec/fixtures directory, then updated the generate_certs.sh script to automatically move the necessary files from fixtures to lib/certs once generated.

[Jammjammjamm]

This test kit requires some other file types too, right?

[alisawallace]

I updated the gemspec to account for the .key and .pem files needed in lib/certs (not sure I did so correctly).

Relating to my other comment on moving the certs back to lib: the cert and CRL generation process requires several config files, so I left all of that stuff in the fixtures directory and only included the files being read by the DefaultCertFileLoader module to lib. All the other stuff in fixtures is only ever used by either the shell script or the spec tests.