Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: Infrastructure
-
Labels:None
Description
LSST can enforce data access rights through group membership. Furthermore, LSST intends to enforce L3 data access rights through group membership. Since we intend on using LSST groups membership to determine data access rights and access to other LSST resources and services, a group naming convention must be established.
Since we intend on enforcing access, data rights, etc. through group membership it would be prudent to have a group naming policy that reflects LSST's information classification policy and account roles within the organization.
The proposed group naming policy:
https://confluence.lsstcorp.org/display/LAAIM/LSST+IaM+Group+Naming+and+Auditing+Policy
Attachments
Activity
Yes we should have a call. However, I would like to point out that we are in agreement: we fully expect users to create their own L3 groups and manage them themselves.
Alexander Withers [X] (Inactive)
added a comment - Yes we should have a call. However, I would like to point out that we are in agreement: we fully expect users to create their own L3 groups and manage them themselves. While reading the group naming convention, I read the LPM-122 too. It seems odd that the category "internal" is less sensitive than "protected user". As LSST internal staff, I may need to access user generated Level 3 data do do debug or resolve issues. Also one example in "protected user" category is "Released LSST Level 2 products" which I think all internal staff should have access to without having to get extra permission.
I'm a little worried about explicitly supporting blacklists other than the global blacklist. My main concern is that it seems like a fine model for services, but doesn't apply as obviously to filesystem access. That is, the services can deny service at auth time, but the unix filesystem permission model doesn't support black lists.
This ticket is currently being implemented on LSST's LDAP instances.
Implementation ticket:
Alexander Withers [X] (Inactive)
added a comment - This ticket is currently being implemented on LSST's LDAP instances.
Implementation ticket:
https://jira.ncsa.illinois.edu/browse/LSST-1114 
We would like to link this up with the Data Access Working Group - I see you mention it in a related page. Also I am not sure we want level 3 groups to be the same mechanism as this - for me the l3 groups could be quite dynamic and created by the users themselves. We should have a call on the topic perhaps easiest.