Define our needs for authentication in Prototype, MVP (and consider beyond)

[willusds]

User story: As a developer for the POC app, I need to know the type and scale of authentication services for different use cases for our app to fully function.

Describe the solution you'd like and the specific acceptance criteria to be completed Narrow our needs for authentication services for the Prototype and MVP of the POC app, considering also the long term scale beyond the MVP. Define the security needs, user classes, authentication levels and other specific needs to help inform our decision on selecting an Auth solution.

Additional context Collecting research and notes here: https://drive.google.com/drive/folders/1gFnRUE91LGCaIuWZ-sJe6S0lUAL9bDzf

Acceptance Criteria A detailed explanation of the number of users, authentication processes needed for launching a prototype, mvp, and beyond we can compare against vendor offerings to make a decision.

• [x] Identify constraints for the pilot (number of users, level of IAL, etc.)
• [x] Pick a solution for the pilot
• [x] Communicate and document the decision

[aliciabeckett-gov]

@willusds would it make sense to split this into 2 tickets- 1) Pick an auth provider for the MVP (<X users, for example 100) 2) Pick an auth provider for scale (when and if we really really roll this out to the world)

1 seems urgent to me, like definitely needs to be done this coming sprint. 2 could take more time and has more room for research and planning.

@benwarfield-usds FYI

[benwarfield-usds]

Doesn't really make that much of a difference—we might select a different short term strategy than long term, but the decision-making process needs to look at the options either way.

I am still not sure what other people are doing in this space, but I think we probably have most of the data we need for this, and can get the rest pretty quickly.

[aliciabeckett-gov]

That sounds right to me. What do we need to do to get to a decision?

[benwarfield-usds]

Not quite off the top of my head:

Business questions in general:

• what are is the actual (not guessing) IAL requirement for users of this application (is there a difference between managerial and test-administration roles?)
• what are the existing systems (if any) by which public health departments verify the provenance of data they receive from POC testing facilities?

Business questions for the pilot:

• how many users do we expect to have for the pilot phase?
• is there any system that we know all of those users have existing credentials for?
• do we expect PDH to handle all of our transmission woes, or do we need an interim solution that involves weird shenanigans with CSV?

Candidate questions for auth:

• how fast can this system onboard a new application?
• how fast can this system onboard a new user, at the desired level of assurance?
• does this system's identity assurance process reliably actually work for users? (This may be hard to get a straight answer for)
• how much will it cost us to use this system in the long run?
• is there any specific reason why this system is better for one or more groups of users? (e.g. NHSN users, colleges and universities, veterans organizations)

Wild cards, probably can be deferred:

• are there users (e.g. universities) who have their own SSO systems they will want to use?
• do any of the candidates have role-management facilities built in?
• are there users who have their own SSO systems that also include role management, and would like to use that instead of whatever experience we build?

[benwarfield-usds]

Oh, and for the longer term, we should pay attention to whether using this tool constrains us in the future in ways that we will not like. 😕

[aliciabeckett-gov]

• what are is the actual (not guessing) IAL requirement for users of this application (is there a difference between managerial and test-administration roles?)

Nick Robinson can help us get this.

Let's assume there is only one role for the pilot, but likely we will have multiple roles in the future.

[aliciabeckett-gov]

• what are the existing systems (if any) by which public health departments verify the provenance of data they receive from POC testing facilities?

@RickHawesUSDS @jlusds @drew-usds can you answer this?

Business questions for the pilot:

• how many users do we expect to have for the pilot phase?

Let's say no more than ~1000 unique users at ~100 organizations. If that's a problem let's talk about it.

• is there any system that we know all of those users have existing credentials for?

No. (SNFs have NHSN but we are starting with Long Term Care Facilities. The google form required by the state does not need authentication, and the Pima county line list is via Excel.)

• do we expect PDH to handle all of our transmission woes, or do we need an interim solution that involves weird shenanigans with CSV?

I think this is a problem for the data hub right? @RickHawesUSDS thoughts?

[aliciabeckett-gov]

Let's defer the wildcards if possible. Universities likely will want to use their own SSO auth systems longer term. If we can do that soon great, if not we can push it out, but that's not the first priority.

[nickrobison-usds]

Hi folks.

Chiming in with a couple of thoughts.

I think for the shorterm/longterm phases of the project, both should target HHS Okta for authentication. Given that PHI data requires LOA (or whatever it's called now) level 3, we need some way to ensure that associated accounts meet these requirements. At CMS, we synchronized with user databases between a number of different auth systems, so if we end up in a position where we need to work with another organization's SSO, we can make that happen. There will still need to be specific processes in place to ensure RIDP happens. There are a couple of ways to make this happen. For HHS Protect, we do paper access forms with PIV signing, which I believe meets those requirements. Kevin Duvall in OCIO would have more information there.

Do you have an existing contact on the HHS Okta account? If not, I can probably help set something up. I've work with the Okta federal folks before, they're pretty solid.

We can work with specific role authorizations as we get further along, it's a pretty simple matter of adding additional assertions to the Okta record. Likewise, we can do role synchronization between federated partners, if we want. I know we've done SAML passthrough before, which would easily make CDC SAMS available, if that's not already done.

Not sure if this is helpful or not, happy to help facilitate more in-depth discussions going forward.

[willusds]

@nickrobison-usds That would be excellent to get an OKTA trial account. Can you help facilitate that? Thanks for your help!

[willusds]

Word on the street: SAMS accounts might be able to be linked through OKTA!

[benwarfield-usds]

Memorializing a recent discussion: under applicable laws/regs, HHS requires users who are requesting access to sensitive or non-public information (which PHI certainly is), to complete IAL2 verification, which may be remote (using Okta) or in-person (using SAMS). Since SAMS does not appear to support IAL2 remote verification, it's pretty much guaranteed to be a bottleneck if we use SAMS with IAL > 1.

[benwarfield-usds]

Considering that we are pretty definitely deploying to Azure for the pilot, we can strike Amazon Cognito off the list. This leaves the below candidates for the pilot. Definition of terms in case of confusion:

• Authentication is when you enter a username and password, and we then know that you are the owner of that username (and nothing else)
• Identify Verification is when we establish a high-confidence link (how high depends on our security requirements) between a username and an actual person in the world. Remote identity verification typically uses government-issued documents or knowledge of the person's financial history to establish this link; in-person verification relies on the persons identity being proven to an authenticating agent. If users can be manually verified by somebody who knows them (e.g. their employer), this should not be needed, but it may be required by CDC internal standards.
• Authorization is when we look to see what the owner of a particular username is allowed to do. In this case, we will at minimum be verifying that the user is authorized to view and modify a specific organization's data; we may also wish to differentiate between roles within an organization, or we may defer that feature.
• MFA (Multi-factor authentication) is a requirement for NIST AAL2, which is a requirement for us to not have a breach the first time somebody tries a spear-phishing attack on our users. Some identity systems require this for all users, while others merely suggest it. If we use one that merely suggests it, we would need to somehow verify that the our users are using it (this is not an uncommon requirement, it's just an additional step we'd have to take). A system that either requires MFA for all users or can be made to require it for all of our users would be preferable; a system that supports it and allows us to check if a user has it configured (so we can lock them out if they don't) is required.

Authentication	Authorization	MFA?	Notes
SAMS	New build	Supported weakly	Requires in-person identity verification
login.gov	New build	Always required	Supports remote IAL2 verification
Azure App Service with federation to Google or O365	Azure AD + some custom code or trickiness	Need to check the assertions of the IDP	Also known as "Easy Auth". No remote identity verification.
Okta	Also Okta	Can be required	Supports remote IAL2 verification
Customer SSO Federation	New build or a bunch of twitchy configuration	Who knows?	Does not seem like anybody actually wants this yet.

Building a role-management system, either hosted on the same database as our primary data store or otherwise, is something we will eventually probably want to do, but if we can avoid it, we should. That being the case, I think we should strike the first two options. And, as noted, nobody seems to much care about using a federated approach, at least for the first few users, so I think we can dismiss that one (and we already dismissed the AWS-native solution, because, well).

[aliciabeckett-gov]

Has the auth provider been decided? @nickrobison-usds @benwarfield-usds @RickHawesUSDS @timothybest-usds

[nickrobison-usds]

Yes, we're going with HHS Okta, starting with a trial account and moving towards a full provisioning soon.

[willusds]

I think we're ready to close this!