ITRFC-12 - Getting issue details... STATUS

Note: this document has been updated for clarification and to ensure consistency with LPM-261.  For example, previous instances required a "data release" tag in the group name which has since been removed since LPM-261 confers and revokes data rights as all or nothing and does not assign data rights at a granular level.

User Groups

LSST can enforce data access rights through group membership.  Furthermore, LSST intends to enforce User-Generated 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. Groups must adhere to the following format:


<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 unless a convention supersedes this, see examples below.

<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.

<UG> → this prefix, using the string “UG”, designates a User-Generated data access rights group.  In this context, the <identifier> string is used to name the specific UG data access rights group.  This string must be present if the “UG” 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.

Data Levels

LSST's information classification policy, LPM-122, defines the following information categories that are used to designate the "data-level". These categories are listed in order of increasing sensitivity.

  • Shareable - Information that is not confidential and can be made public without any adverse implications.  data-level tag name: share
  • Internal - Access to and use of this information is broadly accessible to project staff and others authorized by project management. data-level tag name: internal
  • Protected User - Scientific data and operational metadata reserved for authorized data consumers. data-level tag name: protu

The following information categories must not have groups created at their respective "data-level" without prior LSST project and ISO approval:

  • Sensitive - Limited access only. Access should not be granted to broad groups of people.
  • Highly Sensitive - Information associated with regulatory or contractual burdens that require specific compliance planning or controls.


Users can have a group automatically created upon account creation.  This group serves as a namespace over which they have control.  For example, the user jbasney, would have the group lsst_jbasney.  The user jbasney could then create and manage (i.e. determine membership of) a group called lsst_jbasney_galaxyXYZ.  This group could then be used to control access to user generated data products.  Note that technically the <data-level> is implying "shareable" as the information classification but if this group is being used to control access to user generated data products then the <data-level> is "protected user".

Access groups can be created, for example lsst_portal, that a typical LSST user would be added to during account creation and the data rights access workflow.

During account creation, users must go through an automated (or potentially manual) process to determine their data access rights. This process will automatically add users to preexisting groups that grant them access to non-public LSST data.  For example, the user jbasney has been determined to be a US Astronomer and thus is granted access to lsst_protu.

Staff Groups

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


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:


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 and

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.


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:

Old Group Name

Proposed New Name




LSST Alert Production team within DM (University of Washington)



Group for access to the AWS portal for LSST project usage.



LSST users of Illinois AWS services through NCSA IDP



LSST Camera Control Systems admins



LSST administrative developers for the DAQ Teststand



Users of LSST DAQ system



LSST Data Access and Database team within DM (SLAC)



LSST Data Release Production team within DM (Princeton)



LSST Disabled Users When users need to be disabled quickly, they can be added to this group. This can be used for security issues and/or for users no longer part of the project.



LSST Education & Public Outreach team (external to DM)



LSST hardware administrators, e.g. support vendors



Legacy LSST Image Simulation Group



LSST Infrastructure (NCSA) team within DM

lsst_int_bastionlsst_int_bastionUsers who have access to lsst-bastion* server(s)



ATS (Auxiliary Telescope System / Spectrograph) users of the data backbone service.

lsst_int_kuberneteslsst_int_kubernetesUsers who have access to log into Kubernetes



Initial group of test users for Jupyter Hub



Leaders of LSST



Users of the general LSST project in Nebula OpenStack



LSST International Communications (aka Long Haul Networks) and Base Site (NOAO)



Group for DBA and system admins of the LSST database enclave. for lsst-dev-ora*



LSST Processing Control team within DM (NCSA)



LSST Security (NCSA)



LSST SQuaRE - Science Quality and Reliability Engineering team within DM (LSST/AURA)



LSST Science User Interface and Tools team within DM (IPAC)



LSST System Administration at NCSA rename from grp_lsst_admin

lsst_storagelsst_int_ncsa_setNCSA Storage team assigned to LSST
lsst_int_ncsa_irstlsst_int_ncsa_irstNCSA Incident Response and Security team assigned to LSST
lsst_networkinglsst_int_ncsa_nerdNCSA Networking team assigned to LSST
lsst_sysadminlsst_int_ncsa_sysadminNCSA Systems Administration team assigned to LSST
lsst_itslsst_int_ncsa_itsNCSA IT Services team assigned to LSST
lsst_int_ncsa_iddslsst_int_ncsa_iddsNCSA Integrated Data and Database Services team assigned to LSST



LSST Observational Control System administrators



LSST Telescope Control System administrators



LSST Telescope and Site team (external to DM)

lsst_userslsst_staffActive LSST ‘staff’ (pruned from historical lsst_users)



All LSST users (active and historical) - generated dynamically from join of all other 'lsst_*' groups



Users of the LSST vSphere Mac VM environment

  • No labels

1 Comment

  1. The only caveat I've got is that we need to keep the arbitrary identifiers pretty short since there's a 32-char limit on group name length.  But it looks like the longest here are on the order of 20 characters, so I think we're fine.