Revisit machine-to-machine authentication strategy.

[adunkman]

As the Court, so that we can provide programmatic access securely, we need to grant authorized programs access to data.

Notes:

There are two machine-to-machine authentication situations in play currently:

1. Data migration. The migration scripts need to authenticate with the migration endpoints in order to function. The current strategy, quoting from @michael-mcvicker:

   Not sure how it got there, but a Cognito account was made for my email address. Could have been Waldo entering it by hand, or in the deployment script? The issue was clerkofthecourt role doesn't appear to have permissions to migrate cases, so the Cognito account created needs an "admin" role (albeit we still have to manually add a token). If we can forego Cognito and just use an API Key leaving Cognito accounts for actual users, that would be ideal.

2. Automated processes from the IRS. The IRS needs to pull documents into their system when served in order to effectively process cases. The current strategy:

   • A Cognito user account exists with multi-factor authentication enabled.
   • A human logs into that account once every 30 days to retrieve an access token and refresh token.
   • Those tokens are handed off to an automated script, which uses those tokens to access the EF-CMS API when triggered by email notifications.
   • Before 30 days, the refresh token must be regenerated.

[waldoj]

Not sure how it got there, but a Cognito account was made for my email address. Could have been Waldo entering it by hand, or in the deployment script?

I worked with Mike and Jessica to create that account in perhaps late March. It was created manually, using a make-one-account script purpose-built by Flexion for the purpose of creating that account for Mike. The work was done with some urgency, because Mike wanted to perform all migration work within AWS (as opposed to within Docker), and it was important to both set up the migration environment and provide him with access to work within it as soon as possible. I worked late one night, uncharacteristically, to ensure that the work was done quickly. When that work was completed, Mike was provided with the password to start working within the environment.

[JessicaMarine]

@adunkman I don't think the following is accurate.

A human logs into that account once every 30 days to retrieve an access token and refresh token.

The IRS has to retrieve an access and refresh every 30 days, but that can be automated/written into the script. When we created the automated IRS Superuser with MFA, that replaced any human log-in capabilities into that account. Currently, the IRS should not have any way to manually log-in as the Superuser.

[michael-mcvicker]

The work was done with some urgency, because Mike wanted to perform all migration work within AWS (as opposed to within Docker), and it was important to both set up the migration environment and provide him with access to work within it as soon as possible. I worked late one night, uncharacteristically, to ensure that the work was done quickly.

Thanks for the extra effort Waldo! The intent has never been to do all migration work within AWS, only to prove out that the end-to-end approach to migration was actually going to work -- which your effort helped solidify. When troubleshooting why I kept receiving "unauthorized" when sending json case file, I also asked AWS Pro Services if they could find something wrong on the data migration configuration. They were confused about why we were trying to use Cognito for machine to machine versus an API Key. Is it because we are reusing APIs that are for end users through the ui as well?

[waldoj]

They were confused about why we were trying to use Cognito for machine to machine versus an API Key. Is it because we are reusing APIs that are for end users through the ui as well?

I don't want to overstep, since I'm not working on this project anymore, so I'll just speak to the decisions that I made while I was involved with it. I never looked to anything other than Cognito to avoid setting up an entirely new authentication path just for a single user, which will only be used for the migration, since that addition comes with a lot of overhead in terms of complexity, security, etc. AWS's API Gateway is surely the canonically right way to do this, but at a high cost of developer time etc. that I don't think is a good trade-off relative to another switch or two in a cURL request.

[JessicaMarine]

They were confused about why we were trying to use Cognito for machine to machine versus an API Key. Is it because we are reusing APIs that are for end users through the ui as well?

I think this would have been a question for Flexion. I'm also a little confused at to why this is just now coming up. When we set the data migration environment up and I sent you an email on April 14th to confirm that, I specifically said "Please note you'll need to get the necessary token from Cognito to gain access to the data load API".

[adunkman]

The IRS has to retrieve an access and refresh every 30 days, but that can be automated/written into the script.

Thanks for the clarification, Jessica!

I also spoke with Cody, who clarified that the intention is to use an automated script with the Cognito SDK, as demonstrated in this example, and have the script store the MFA token generator so it can be fully automated.

I was operating on my understanding of what Arun said in our sync-up call on May 22 — I’ll be sure to get further clarification on their approach in tomorrow’s meeting to see if there are any misunderstandings.

On a meta level, this is quite an interesting approach for authentication for automated services. I’ve reached out to our 18F team to see how others have implemented machine-to-machine authentication, specifically when it crosses agency boundaries — but I don’t think we should hold up work at this time to change approaches.

[michael-mcvicker]

use an automated script with the Cognito SDK, as demonstrated in this example,

That's the same approach I originally took trying to pass a case which seemed to work well in that I could see it getting into the migration environment logs, but kept returning "unauthorized" so ended up passing a token stripped from the wire which had the same "unauthorized" result until the role for the account was changed in the migration environment. I haven't had a chance to go back and put this approach back in but don't want to waste the time unless you think it'll work ?

[vickimcfadden]

@adunkman any thoughts on this one? is it moot now?