XCI Ansible repository
Does the XCI Ansible repository on bitbucket.org require multi-factor authentication for access?
Does the XCI Ansible repository on bitbucket.org require multi-factor authentication for access?
XCI-073_AWS_Information_Services_Design-v0.2.pdf identifies XCI as the "team that implements, operates, and supports XSEDE Information Services."
Why is XSEDE's integration team operating a production service rather than XSEDE operations team?
This is a minor issue and you can ignore it if you prefer. The design document references the four "canonical" (enabling function) use cases for information services, which of course makes sense. It wouldn't hurt (and might help identify important requirements) to also list the more specific us
I've noticed that many of our RACD design documents are missing a requirements section that details the important requirements that need to be satisfied by the design. As a design reviewer, it would be super-helpful to have a clear statement of requirements that I can check the design against.
I think the application developer document could use some clarification on pages 2-3 as to what constitutes "Login with XSEDE" vs. "Login to XSEDE".
We'll need to add a new Usage attribute for JetStream where XDCDB does not have traditional information to identify time used by a Gateway user's job.
Section 5.1 Introduction should mention that the subsequent sections 5.1.x are all design requirements.
Section 5.1.7 "Self-Service required" seems to open the door to a malicious gateway operator obtaining access without human review.
Validating that submitted data is semantically relevant is extremely important when trying to use or report on the data. Section 5.1.4 (or a section in the Implementation/Technical details) should further elaborate on how this validation will be performed.
The gateway registration information will be stored in an SQLlite database rather than the XDCDB. This means that backup and recovery is not covered by an existing process. What processes, if any, will be put into place for disaster recovery?
From an XSEDE perspective, all we care about is that users authenticated using acceptable credentials have an XSEDE identity that can be mapped locally. This design doesn't mention the possibility that an SP may also need to map non-XSEDE OAuth identities to local accounts.