Shut down my.usa.gov (MyUSA)

[yozlet]

It's time to send MyUSA to the authentication service farm upstate where it can run around with the other OAuth2 gateways, chase PII and eat all the budget it likes.

Reasoning

We have too few people and resources to be able to maintain the MyUSA service. The code is gradually bit-rotting due to its reliance on outdated versions of key Ruby gems. As this continues, our ability to safely maintain and deploy it is being eroded.

This wouldn't be such a grave situation if there weren't still active projects depending on it. We need to definitively announce closure and coax dependent projects to move to alternative authentication & authorization services.

Plan

Pre-shutdown

• Gather list of active dependent apps
• Gather list of alternative auth systems for apps to switch to
• See if there are any wider GSA stakeholders (unlikely to be many, probably none) we need to run this past
• Investigate requirements around PII disposal - any record retention requirements?
• When does the ATO expire? (Was there actually a final ATO?)
• Tell GSA Privacy so they can take down the SORN (acc. to Noah)
• Have all dependent apps switch away to alternatives
  • C2 (issue)
  • Open Opportunities (issue)
  • Dolores (issue, PR)
  • Tock (issue)
  • Handbook (aiming for 8/4 - issue)
  • 18F Pages (-staging and -internal)
  • Team API
  • Hub (probably ok to shut down)
• Update MyUSA's README to note project deprecation
  • ... and https://github.com/18F/omniauth-myusa
  • ... and then push omniauth-myusa to RubyGems so it's updated there too

Shutdown

• Learn about formal decommissioning and its requirements (probably from Noah)
• Announcements?
  • 18F blog post?
  • Anywhere else?
• Close social media accounts
  • https://twitter.com/myusa
  • https://twitter.com/ProjectMyUSA
  • https://twitter.com/ProjectMyGov
  • https://www.facebook.com/ProjectMyUSA/
• Create new landing page for old MyUSA URLs
• Point domains at new landing page login.gov
• Gather list of AWS MyUSA components for cleanup
• Shut down and remove MyUSA from CF
• Clean up AWS components
  • Databases and their backup snapshots
  • Anything else?
• Remove MyUSA API from data.gov inventory
• Write a report on all the above as (monument to the glory of all who worked on this)/(warning to future generations of what happens if you don't clean up after yourself)
• Give remaining artifacts a Viking burial from Ocean Beach

[jeremiak]

You can remove Handbook from the list, @yozlet.

The documentation working group has a goal of 8/4 to make the Handbook public and are tracking our progress in GSA-TTS/handbook#829

[yozlet]

Thanks @jeremiak! I'll keep Handbook in the list for the moment (since it's still a dependent) but link the issue.

[StephenOTT]

What was the final count of apps and departments that were using MyUSA?

[jackiekazil]

[yozlet]

@StephenOTT: Five apps, all 18F (though a couple of those were for users outside 18F, but still within government). See the nested list in the issue checklist.

[StephenOTT]

@yozlet ah! haha, I read that list as those were the alternative apps systems could validate against. Now that i look at the list in more details, that assumption does not make much sense :)

Thanks

[yozlet]

@StephenOTT Yep, sorry if that wasn't clear! Will be providing the list of alternative auth systems shortly.

[yozlet]

@StephenOTT Thanks! Looks impressive, but this isn't the best place to discuss it. Let's chat elsewhere. :)

[pkarman]

https://docs.cloud.gov/apps/leveraging-authentication/ is good alternative for something like C2 (which is all GSA users)

[yozlet]

Thanks @pkarman! Yep, the current alternative auth methods list looks like this (and I'll keep this comment updated):

Cloud.gov Auth

See information here

Pros:

• OAuth2
• Can use existing GSA login or add new accounts, can also backend to other existing gov auth systems if needed
• Actively maintained, and very likely to remain so
• Already has at least one client implementation example (Python)
• Maintained by us, so chance of getting features added if needed; the team is eager to talk to potential client app teams; mmm, yummy dogfood

Cons:

• Still relatively immature
• While Cloud.gov is aiming to become a rock-solid highly-available platform, it's not there yet
• Users expecting MyUSA will need extra training (looking at C2 here)
• Only sends over email address, not other profile details (which is probably fine for most of our needs)
• Can't verify that user is 18F staff (but then, neither could MyUSA)

GitHub Auth

Pros:

• OAuth2
• Tons of existing client implementations, should be very easy to integrate
• Highly-available, mature
• Can verify that user is part of 18F team if needed
• 18F users are likely to be logged-in already, so fast click-through

Cons:

• Only a good option if all users are guaranteed to have GitHub accounts; otherwise, imposes a higher registration/training barrier than other options

Google Auth

Pros:

• OAuth2
• Tons of existing client implementations, should be very easy to integrate
• Highly-available, mature
• Almost all GSA/18F users are likely to be logged in already, so very fast click-through
• It's Google! Everyone knows Google!

Cons:

• Can't verify that user is 18F staff (but then, neither could MyUSA)
• Really? We're using Google?

MAX.gov

Pros:

• Intended for gov-2-gov auth
• Already delegates to a load of existing agency auth systems (but not GSA)
• Can authenticate using PIV cards
• Relatively mature

Cons:

• No OAuth2, only SAML
• The topic of UX appears to be somewhat subdued within their priority matrix
• Does not currently delegate to GSA SecureAuth

Not in this list: login.gov. (because it's too far from ready, and also it's not meant for gov-to-gov auth)

[harrisj]

I added an item to remove MyUSA from the the data.gov inventory once the AWS instances have been shut down. This is not a difficult process (it just means sending an email and @gbinal or I can handle it), but I wanted to add it to the list.