Specify existing academic environment requirements for access control to operations data about blueprint HOT 20 CLOSED

from blueprint.

Yes, nice summary @billburnseh

from blueprint.

related issue #76 #77 #30

from blueprint.

1. SSO systems are already in use in universities and research centers. The two most common identity and access management systems are Globus for researchers (https://www.globus.org/ ) and InCommon for US students (https://www.incommon.org/solutions/). Requirement: Academic users will use the SSO system their university designates to access Operate First services and data.
2. Academic environments have public policies about acceptable use of their facilities. This allows them to specify who has access to services and data, and under what conditions that access can be revoked. The AUP can also specify conditions of use (such as no expectation of privacy). CloudLab has an excellent policy that has been successfully used for academic operations for many years: https://www.cloudlab.us/aup.php Requirement: Operate First will use identities from requirement #1 to manage access to services and data in keeping with the facility AUP. Only users with an active Operate First account may access services and data. (Derived requirement: Operate First environment will publish an AUP. This will require academic review.)
3. The onboarding process for an academic environment ensures that each user views the AUP. Using your account means you accept the AUP. (Academic environments almost never have license agreements for end users.) Requirement: Onboarding for Operate First includes showing users the AUP. (Derived requirement: Operate First users whose accounts predate the AUP must be contacted so they can view and accept the AUP.)
4. Academic environments may further limit access to specific operations data to a subset of users for privacy or security reasons. This level of access restriction cannot be supported in Operate First. Another way to express this is that the AUP must specify that operations data is available to all users with active accounts. Requirement: Operate First will not collect or store operations data that requires restricting data access to a subset of all active Operate First users. (This will require academic reviewers. This requirement also negates the need for a privacy policy. See https://www.globus.org/legal/privacy for a privacy policy successfully used for many years in Globus.)
   NONE of items 1-4 are actually legal agreements or contracts, so it is relatively straightforward to create and publish them.
5. If data is transferred into or out of an academic environment, the university requires an approved data use agreement. The university may also require approval from an Institutional Review Board for data that involves human subjects. Examples for BU: https://www.bu.edu/researchsupport/forms-policies/data-use-agreement-form/ ://www.bu.edu/researchsupport/profile/institutional-review-board-irb/ Although the examples for these agreements are complex, in practice many data centers already have DUAs and IRB approvals for environments like Operate First. Michael Daitzman is working to get DUA and (if necessary) IRB approval in advance of prodcution deployment for Operate First data. Requirement: Operate First data will not be transferred into or out of the Operate First environment until we have an approved DUA and (if necessary) IRB approval from BU.

from blueprint.

Asked Michael Daitzman to review requirements.

from blueprint.

Looks good. I'll use it as a basis for discussions with legal, etc. who may have some stuff to add in.

from blueprint.

Thanks, those requirements are pretty extensive :)
If one of those influences a design decision, we should pull them into the ADR.

Can we start with the SSO ADR?
#74

@tumido made a point to aggregate SSO from multiple sources

from blueprint.

Great info. So the AUP would negate the need for a EULA, but perhaps may need some language to cover the data and it's licensing.... (not a lawyer).

from blueprint.

Based on your excellent explanations....credit where credit is due! Thanks!

from blueprint.

Thank you @hpdempsey ! 👍

I think we need to consider "mingling" and interaction of 2 kinds of users - those who have access to research institutions and can login via academic SSOs and those who can't - independent users, RH/IBM/other engineers, users accessing a demo or attending a workshop, which requires them to interact with the platform (e.g. ODH demos for deploying various components etc.).

Both these types of users want to access our platform. While the first can login via academic SSO, the later one can login via email or possibly github only (Those are the only credentials we can use to identify them and are least intrusive.) For these users we still have the need for an EULA in some form.

Mind that those non-academic users are also interested in taking data in/out of the platform.

Additionally to that Operate First will soon operate clusters outside of MOC, which doesn't have this DUAs and IRBs that are enforced MOC. I'm not sure how we want to implement that, since we would like to have unified experience for all of the users, while it doesn't make any sense for a user accessing non-MOC cluster to have to comply with MOC policies directly (like being presented with MOC AUP).

While I understand the need for privacy policy and EULAs and what not, I'm not versed in this topic at all. So feel free to tell me if I'm totally missing the point now. 🙂

from blueprint.

Aand I've just read the Data license choice for Operate First email thread. Some of my concerns are already voiced there or explained. Just don't mind me 😄

from blueprint.

I'd love to see the thread @tumido referenced above. Re. SSO and academic above - two of the major academic login options both route via cilogon.org which includes both google (many companies including redhat.com logins) and GitHub as oauth providers so that they support non-academic users. Not sure of the "rules of engagement" for them.

from blueprint.

@msdisme forwarded 🙂

from blueprint.

2 examples for Acceptable Use Policy

https://www.osgconnect.net/aup
https://www.chameleoncloud.org/terms/

from blueprint.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from blueprint.

/remove-lifecycle stale

from blueprint.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from blueprint.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

from blueprint.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

from blueprint.

@sesheta: Closing this issue.

from blueprint.