User Groups

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.

lsst_<data-level>_<data-release>_[<identifier>|<L3>_<identifier>]

<data-level> →  this optional prefix maps to the information classification policy as defined in LPM-122.  This identifier cannot be an arbitrary string and must use one of the designated names as set forth in LPM-122.  If this prefix is absent then “shareable” is assumed.

<data-release> → this optional prefix is used to narrow data access rights by specific Data Release.  This prefix cannot be specified if <data-level> is not specified. If this prefix is not specified then it is assumed the members of the group have access to all data as specified in the <data-level> prefix, regardless of which Data Release is being accessed. <data-release> must be in the format of “DR#”, where “#” is a positive integer.

<identifier> → this optional prefix is an arbitrary field that can be used to designate the context in which the group grants resource access or data access rights.  Also, it can be used to designate a group in which membership is denied access to a specific service, resource or Data Release.  For example:  “comcluster” might be used to designate those with access to the commissioning cluster where “notebookBL” might be used to designate those denied access to the notebook Aspect in the science platform. In terms of LSST’s security policy this prefix shouldn’t be used if a general case is sufficient for access.

<L3> → this prefix, using the string “L3”, designates a Level 3 data access rights group.  In this context, the <identifier> string is used to name the specific L3 data access rights group.  This string must be present if the “L3” prefix is used.

When new groups are created that share a prefix, the requirement is that any defined group “lsst_N” is a superset of any subgroups, i.e. “lsst_N_1”, “lsst_N_2”.  This requirement is made with the understanding that LDAP does not have a notion of subgroups and cannot enforce this requirement.  It is expected to be enforced through LSST’s identity management auditing process.

Note: the above scheme allows for a group name of "lsst".  This is an alias of "lsst_users".  Also, if optional prefixes are not present then the underscores are not needed.

Staff Groups

For internal LSST staff, default groups hall be created with the prefix of:

lsst_internal_<identifier>

It is assumed that any member of these groups have broad access to LSST data classified as “internal” or lower as detailed in LPM-122.

For internal LSST staff that require admin privileges, default groups shall be created with the prefix of:

lsst_admin_<identifier>

It is assumed that any member of these groups have broad access to LSST data classified as “highly sensitive” or lower as detailed in LPM-122.  Obviously this means LSST staff in these groups have access to any data due to the ability to escalate their privileges.  Membership in these groups needs to be carefully planned.

For both of these group prefixes:

<identifier> → an arbitrary field used to designate the context in which the group grants service or resource access.  Also, it can be used to designate a group in which membership is denied access to a specific service or resource.  In terms of LSST’s security policy this prefix shouldn’t be used if a general case is sufficient for access.

Default Groups and Hierarchy

lsst_users - All LSST users placed in this group.  See https://confluence.lsstcorp.org/display/LAAIM/Granting%2BData%2BAccess%2BRights and https://docs.google.com/document/d/1AKjIiYiBr7tenl5ZlNGypc2n8xqWK2SSmTDUCMJjxvQ/edit

lsst_staff - All LSST staff, equivalent to lsst_internal_staff.  This group has broad access to LSST data classified as “internal” or lower as detailed in LPM-122.

lsst_admin - All LSST staff requiring administrative privileges on any particular service or resource.  In general, this group should not be used.  Instead, specify specific groups according the “lsst_admin_” prefix scheme specified above.  This group provides a quick way to list all accounts requiring admin privileges and can also be used to quickly revoke those privileges.

lsst_disabled - LSST disabled accounts. Users or staff that need to be disabled quickly can be added to this group. This is normally used for security issues and/or for users no longer part of the project.

Abbreviations

In the case where LDAP, Linux, POSIX standards, etc. enforces character limits in group names, abbreviations may be used in a consistent fashion.  For example:  lsst_admin_* could be lsst_adm_*.

Historical Groups

The following defined groups are currently in existence at the NCSA.  They do not necessarily conform to the naming conventions above.  However, they are all assumed to be composed of internal LSST staff. Since many of these group names follow LSST’s organizational structure under its construction phase, it is assumed that most of these groups will no longer be needed when LSST moves into the operations phase.  If possible, these groups should be renamed to follow the “lsst_internal_<identifier>” convention specified above. (see: https://docs.google.com/spreadsheets/d/14VE13S8fYWtE8bCa_K4AQ79TFak2DTAH-n9L4sB2rB4/edit#gid=0)