Please post design and security comments and suggestions as replies to this message.
Research Software Portal
Provided by ACCESS
XCI-691 COmanage Design and Security Feedback
Fri, 2021-03-05 17:55
#1
XCI-691 COmanage Design and Security Feedback
© ACCESS All Rights Reserved.
ACCESS is an advanced computing and data resource supported by the
National Science Foundation
and made possible through these lead institutions and their partners:
Carnegie Mellon University,
University of Colorado Boulder,
University of Illinois at Urbana-Champaign, and
State University of New York at Buffalo .
Administrative Login
The XSEDE username is the primary key for user records. The preferred data model is that each XSEDE staff member has one and only one XSEDE username. If, however, the state arises that an XSEDE staff member has two or more XSEDE usernames in the XDCDB then it is possible that the staff member will end up with two or more CO Person records in COmanage. When two CO Person records in the XDCDB are manually merged, they should also be manually merged in COmanage. The merging is to be done by hand by a CO Administrator with the necessary permissions, being careful to consider the details for merging other identifiers and group memberships managed in COmanage, as well as the downstream effects on provisioned services such as Jira.
D.1. states "The user’s XSEDE manager logs into COmanage and uses COU Administrator privileges to execute an Invitation Enrollment Flow to onboard the new staff member into the COmanage platform.". Did Leslie and the program office decide this is who should do this, versus for example project managers who also perform many of the onboarding activities? I understand that COmanage doesn't care, and this is more of a policy and responsibility question. At a minimum, I think both the manager and associate project managers should be able to initiate the Enrollment Flow. Or, do we need to clarify the term "manager" in the design document to indicate if this is a COmanage defined role that corresponds to WBS managers and project managers, or if it's different? I see that "WBS manager" is also used elsewhere in the design. This could be addressed by making using the term "manager" more consistently.
The above observation about the meaning of "manager" applies in "The user may also automatically be added to other CO Groups as configured and the manager may directly add the user as necessary to closed CO Groups.".
In D.3. please explain who "Delegated XSEDE staff" refers to and give examples of OIDC RP clients that would use the CILogon Proxy as the OP. The second paragraph in D.3. is heavy on jargon, and could try to explain what this means to other developers and security staff so it's clear what Proxy Functions do.
In E.2.12. would it be good to suggest that XSEDE setup Inca and/or Nagios tests of the XSEDE's CoManage front-end? Would it be good for XSEDE to monitor anything about the CoManage instance besides the web front-end?
In E.2.13. could you please indicate if CoManage also logs logins and could produce standard XSEDE usage records based on those logs? That could be a separate activity, but one we'll want to complete before all phases of CoManage are delivered.
Are members of an L3 WBS group automatically members of the corresponding L2 WBS group? If not, which may make sense, could there be automatically generated L2-ALL groups (e.g. "WBS 2.3 ALL") that automatically merges the L2 and corresponding L3s? I think we have e-mails lists that would be driven by these ALL groups. Or, do we expect Majordomo to create these "ALL" groups by manually configuring all the WBS groups it queries for the membership list? Seems to me that CoManage is the best place to create these "union of other groups" groups.
I have updated the design document with additional and/or clarifying text to address each of the issues/questions that are labeled with a section (e.g. E.2.13). The edits may be found in those sections for the updated document.
Regarding the last question on L3 WBS group membership, I have added clarifying text in section C "System Overview". For convience the text is duplicated here:
Note that members of a L3 WBS COU Members Group-Active are not automatically members of the L2 WBS COU Members Group-Active. Effective L2 WBS “active” and “all” groups, however, may be created using COmanage Nested Group functionality by making the L3 WBS COU Members Group-Active groups source groups for the effective L2 WBS target groups. These L2 WBS “active” and “all” groups may be especially useful for mailing list management.
D1--a project manager will likely be the one to log into COmanage to onboard new staff. There is an existing staff onboarding process that we would slot this step into. Is this saying that once they're onboarded they would automatically be assigned a confluence and jira account? I don't know that we want to do that. I would want to consult with Deb Nigra who manages these accounts. Not everyone needs access to Jira, for example.
The text in D1 has been edited to clarify that authorized members of the Program Office will execute the onboarding enrollment flow to onboard new staff members.
Staff do not receive Jira or Confluence accounts by default. An authorized administrator, which may include Program Office staff, will add the user to a group that determines which staff have Jira accounts provisioned. Additionally the user may be added to another group to indicate Confluence access. I have updated the text in section D.4 to clarify.
I had a Zoom call with Chris Lindesy and went over the details of the design for Majordomo integration with him. He concurs with the design and agreed that we should be able to have an end-to-end test with an initial email list (most likely created just for testing) by the end of April, 2021.