Uploaded image for project: 'IT Request For Comments'
  1. IT Request For Comments
  2. ITRFC-12

LSST IaM Group Naming Convention

    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

          Issue Links

            Activity

            awithers Alexander Withers [X] (Inactive) created issue -
            awithers Alexander Withers [X] (Inactive) made changes -
            Field Original Value New Value
            Remote Link This issue links to "Page (Confluence)" [ 16779 ]
            Hide
            womullan Wil O'Mullane added a comment -

            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.

            Show
            womullan Wil O'Mullane added a comment - 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.
            Hide
            awithers 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.

            Show
            awithers 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.
            Hide
            xiuqin Xiuqin Wu [X] (Inactive) added a comment -

            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. 

            Show
            xiuqin Xiuqin Wu [X] (Inactive) added a comment - 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. 
            gpdf Gregory Dubois-Felsmann made changes -
            Remote Link This issue links to "Page (Confluence)" [ 16850 ]
            Hide
            krughoff Simon Krughoff added a comment -

            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.

            Show
            krughoff Simon Krughoff added a comment - 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.
            krughoff Simon Krughoff made changes -
            Risk Score 0
            jkantor Jeff Kantor made changes -
            Status Proposed [ 10805 ] Adopted [ 10806 ]
            Hide
            awithers 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

            Show
            awithers 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
            jkantor Jeff Kantor made changes -
            Resolution Done [ 10000 ]
            Status Adopted [ 10806 ] Implemented [ 11105 ]
            awithers Alexander Withers [X] (Inactive) made changes -
            Remote Link This issue links to "Page (Confluence)" [ 18500 ]
            awithers Alexander Withers [X] (Inactive) made changes -
            Remote Link This issue links to "Page (Confluence)" [ 18500 ]

              People

              • Assignee:
                awithers Alexander Withers [X] (Inactive)
                Reporter:
                awithers Alexander Withers [X] (Inactive)
                Watchers:
                Alexander Withers [X] (Inactive), James Basney, Simon Krughoff, Wil O'Mullane, Xiuqin Wu [X] (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel