GAWB-3166: Need a EULA in UI and API that users agree to

[irosenbe]

Requirements
Auditors have decided that we need an End User License Agreement for Firecloud/multi-tenant application.

1. Get a EULA from our lawyers - In progress; Will provide the verbiage this week
2. Post it to FireCloud UI - See "User Flow" in comments

• For current and future users. For current users, can put a modal up requiring the user to click through the EULA since these users do not see the registration page
• Keep the workflow going if a current user rejects the TOS but has a job running
• "Cancel" and "Accept" options - If hit cancel, log out of FC. Log back in and see the modal again. Would have to ensure to end permissions such that the jobs keep running so when user logs back in and accepts, they will see completed jobs

3. Prevent user authorization if they haven't agreed to it (both UI and API)

• UI: see # 2 above
• API: throw an error that says haven't agreed to EULA and then points to an "I agree" endpoint. User can call the endpoint to acknowledge the EULA. Confirmed this is an acceptable definition of acknowledging the terms as long as the user is doing it

4. Have some sort of bypass for users that come into Firecloud from other places (such as AoU).

[Bernick] My feeling from the government requirement is that the users sign some sort of EULA for using "the system". AoU will use FC, but the user is signing into AoU so it has it's own EULA.

But we should take that opportunity to have them sign a EULA for using FC if they want to use FC (not via AoU interface). Maybe have the AoU EULA cover a FC EULA too and this tick the database flag in FC for having signed it? Otherwise, yes when the user comes to FC independently of AoU, they'll have to sign it.

5. Make sure that this is "universal" across FC so if a user comes in through an API in our ecosystem (but not through the "front door" they "sign" the EULA.

[Bernick] Yeah this whole thing is kind of up to you. It's a workflow issue.
If a user comes into firecloud via some "app", the app needs a EULA. Whether that EULA covers FC or not is something we don't have visibility into, but we should probably tick the FC "signed eula in FC box" if they come in through another app and just assume that app has a EULA?

But if they come in through FC (the app) or FC (the services), WE need to keep track of them signing a EULA.

IT IS contradictory and do not have good advice on it since most EULAs don't think about API driven software.

I think I'd say, "we should keep a record of any user using FC Services and Apps as having signed some sort of EULA". That might mean twice signing a EULA for a user.

Date: UI should be ASAP, the remainder can be staggered afterwards anytime this year

Notes:
Remember this isn’t purely a frontend. A user has to agree to a Eula somewhere in their experience. So AoU needs to put in a Eula and have that clicked through. So doesn’t Saturn. And if a user doesn’t use a GUI they shouldn’t get access to any Workbench backend until they can show them that they clicked through a Eula. So it’s not not just GUI thing. Though it CAN start that way. All of our services need the ability to see fin user clicked through a Eula at some stage during account creation.

https://nvd.nist.gov/800-53/Rev4/control/PL-4 this is the control we specifically have to fulfill: – it's (a,b,c,d) that this ticket

Control Description
The organization:
a. Establishes and makes readily available to individuals requiring access to the information system, the rules that describe their responsibilities and expected behavior with regard to information and information system usage;

b. Receives a signed acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the information system;

c. Reviews and updates the rules of behavior [Assignment: organization-defined frequency]; and

d. Requires individuals who have signed a previous version of the rules of behavior to read and re-sign when the rules of behavior are revised/updated.

Outstanding Questions:
https://docs.google.com/document/d/12dGIFtn0xGE4Ld8E91mTShtXt3oEKLJgbw7lxPUrwqw/edit

Link to GAWB Ticket: https://broadinstitute.atlassian.net/browse/GAWB-3166?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel

[irosenbe]

User Flow (# 3 is new functionality):

1. Click "Sign in from Google" from the landing page
2. Navigate to screen to sign in with Google account

3. Once user accepts the Google terms of service, navigate to a new modal that looks similar to the click through for the Onix Terms of Service (see screenshot). Language for this to be provided the week of 4/23. User will need to select "I acknowledge" in order for the "accept" button to be highlighted and user to continue through registration

[irosenbe]

Communication to users: Before this functionality is released, Ilyana will write a blog post explaining that there’s going to be a click-through EULA, a summary of the terms, and reasoning for adding this now to FireCloud

[jmthibault79]

Thought of another wrinkle: make sure this works for Service Account users as well.

[dvoet]

snippet from slack

doge [10:59 AM]
on the EULA front - assuming we only need it when federal data is involved, can we limit it to only when gaining access to said data? perhaps when linking to era commons account?

dbernick [11:01 AM]
from the text of our POAM:
There is some training for Firecloud. The End User License agreement needs to be documented and signed off by people using the portal especially with TCGA/Target/AoU data
sooo that’s alittle vague
but I would agree — MUST with protected data.
But the poam also says:
End User License Agreement must be drafted and presented to all users (risk statement)
So given that, my recommendation was EULA for all users.

(I still think it is worth a little more pushing as it is a good answer for what we do about api-only access)

[irosenbe]

Following TOS language should be included in the click-through: https://docs.google.com/document/d/1i1qUsrF8kI2iuR0cgsxIyicnmfoicKcqiK3M-Fjk8aQ/edit