search

CDCgov / prime-reportstream

ReportStream is a public intermediary tool for delivery of data between different parts of the healthcare ecosystem.
https://reportstream.cdc.gov
Creative Commons Zero v1.0 Universal
70 stars 39 forks source link

Standardize auth code per CDC specification #8597

Open arnejduranovic opened 1 year ago

arnejduranovic commented 1 year ago

User Story:

As a CDC project, I should align with the CDC on the standardization and authorization approach of my applications.

Description/Use Case

Turn RS Auth Code into Building Block Presently, ReportStream implements the two-legged auth approach specified by FHIR. This part appears to be fine. To increase reusability between CDC projects, for example with ETOR, we will need to break out this code into a reusable library.

Identity Providers: CDC is looking to standardize their SAMS system to NIST 800-63. SAMS is a sort-of home grown version of Okta whose purpose is to allow external entities to access CDC datasets and probably does not handle server-server auth. SAMS is old and might be undergoing modernization efforts. If it does, CDC may want us to use it instead of Okta.

Boris (Yu Ning) from the CD recommends we take a look at Keycloak (open source identity provider on the come up) for our Identity Provider. Then he suggests using Login.gov for identity proofing, either via ReportStream -> Keycloak -> SAMS -> Login.gov or maybe ReportStream -> Keycloak -> Login.gov We should set up a meeting with Boris at some point (include Peter from Flexion) to discuss these options further and compare them to Okta and others.

We currently use Okta which is owned by SimpleReport, not ReportStream. We need Identity management of public keys. We do this in our database right now in settings. Can Okta or something else do this?

Risks/Impacts/Considerations

Dev Notes:

TODO: Create spikes to speak with Boris

Acceptance Criteria

arnejduranovic commented 1 year ago

Regarding Keycloak (from @stephenkao):

I think the two interesting things that stuck out to me while I was glancing through the documentation were:

Resource-based permissions in addition to scoped-based permissions. We have the latter with our Okta setup, but as we’re moving toward a self-service model, it could be the case that we’d want to have granularity on resource management like Organizations/Senders/Receivers

Impersonation, which could help with service requests if there’s an issue we can’t reproduce as admins. Not too big of an issue right now because the website isn’t used too frequently, but I could imagine this feature being a huge boon in the future

bishoyayoub commented 1 year ago

@arnejduranovic Can you confirm if we can icebox/reassign these issues and epic to another group?