XCI-826 Design and Security Discussions

I updated the design document (section 6.2.4) with plans for updates to end user documentation and science gateway/developer documentation. I also created a tracking issue for the end user documentation updates (separately from the existing issues for science gateway documentation). I commented on XCI-865 noting that these other Jira issues all exist.

XSEDE never documented or recommended GCS 4.x, which is the only version of Globus Connect that requires migration. Consequently, I don't think XSEDE needs to document (or wait for the availability of) the migration tool. Globus will be happy to work with SDSC (and anyone else related to XSEDE who may be using GCS 4.x) on their migration when the migration tool becomes available, and on 5.4 deployment plans in the meantime.

The introduction paragraph 2 should also highlight the new ability to access data using the HTTPS protocol and tools that support it like web browsers. This is covered in the document, but significant enough to mention in the introduction.

I added this as recommended.

On page 10 it says "When the individual needs to share something, he or she creates a guest collection that addresses a specific directory.". Would this be clearer if worded as "... that _references_ a specific directory"?

I made this change as recommended.

In the same paragraph on page 10, I would assume that "set permissions on directories within the guest collection" refers to Globus managed permissions, and not local Unix permissions. This should be clarified. If these are Globus managed permissions this paragraph should clarify that Globus authorized non-owner user access (as authorized by the owner) and then accesses files as the owner.

I added more detail & clarifying text.

It appears that the recommendation is for the storage gateway for Science Gateway access should use a mapfile that only contains science gateway mappings. This I believe is currently not detailed in the XSEDE GCS v5.4 Installation Guide. That guide should detail how to configure two mapfiles, the one used for XSEDE projects, and the one used for XSEDE Science Gateways.

I agree that the XSEDE installation guide should provide details on how to do this. Note that there are two obvious ways: maintain a separate mapfile that only lists authorized community accounts, or use the complete XSEDE mapfile but also use the --user-allow configuration setting on the storage gateway to explicitly list the authorized community accounts. It's really up to the endpoint administrator to decide whether they prefer to manage a separate mapfile or use the same mapfile and list the allowed community accounts in the storage gateway configuration settings. Can you (JP and Eric) decide how to handle that in the installation guide?

It might be worth mentioning, though not critical, that with GCS v5.4 XSEDE endpoints are now owned and fully managed in the Globus Transfer service by XSEDE SPs themselves. This is a change from previous Globus endpoint deployments where XSEDE created and owned the Globus transfer endpoint.

The goal of this design is to provide a specific configuration of GCS 5.4 and explain how it satisfies XSEDE's use cases and security requirements. We are not reviewing the previous design. I think it's better to focus the attention of XSEDE personnel on the proposed design and its merits (or flaws) than to compare it to the previous design.

Can SPs configure Storage Gateways (Primary and/or Science Gateway related) to only authorize access if the user authenticated with their XSEDE identity and not if they authenticated with any other linked identity? If this is not an XSEDE requirement, or not supported, it should be spelled out.

Section 4.2 of the design enumerates specific access control requirements so they can be referenced later in the design. If XSEDE or XSEDE SPs have that requirement (i.e., there's a specific security risk that this requirement is needed to adequately manage), we can add it to section 4.2. That requirement would not be satisfied by any of the proposed configurations, though.

The access policy you describe (user must authenticate to a specific identity provider to gain access) can be configured under a High Assurance or HIPAA+BAA Globus subscription, but not under a Standard subscription. XSEDE currently has a (custom) Standard subscription. I'll also point out that the user experience that results from that configuration (in which the user must be prompted to authenticate with a specific identity provider when they attempt to access a collection) is more complicated than the usual configuration, where a linked identity is acceptable for data access. Because it's more complicated, it's more prone to user error and to result in user support tickets. In other words, identity linking is a usability & "supportability" feature and shouldn't be disabled without careful thought.

In 6.1.3 the 2nd paragraph should say, "XSEDE's Central Database (XCDB) has a restful API that is accessed by a command-line tool (CLI) for generating these mapfiles". This is because the tool is not provided by the XCDB or its support team. Which XSEDE team provides this tool is probably not important versus the fact that XSEDE does provide both the API and the CLI tool.

Fixed.

On Page 19 recommend updating the "The mechanisms supported by the two endpoints in a transfer need not be the same." and make the "not" bold. I misread it the first time, which might easily happen to others.

I re-worded and also added highlighting to make this less likely to be misread.

Regarding 6.1.5.3, the developer.globus.org service's "Add new Globus Connect Server" interface does not support specifying a "required identity" as it does for "Add a new app". Is this expected?

Yes. Globus Connect Server endpoints enforce authorization policy with a tailored user experience rather than relying on Globus Auth's "blunt force" method to do it for them.

Should 6.1.6.4 clarify that this feature may be used for local non-XSEDE access use cases and is not recommended for XSEDE's use cases? Or does that matter?

Yes. I added text to the section that explains this.

Could the Page 29 paragraph the starts as "A notable interoperability feature that is not satisfied..." mention GridFTP v2 clients that have been used in TeraGrid or XSEDE? Are UberFTP and version of globus-url-copy examples?

Yes. I added text to the section that explains this.