REVIEW-40: XCI-30 Provide InCommon Identity Provider for XSEDE Identities - Design/Security Review

General design and security risk review for a new XSEDE InCommon Identity Provider

The following questions were raised during review:

Does XSEDE Duo exclude the use of SMS-based passcodes according to https://duo.com/blog/duo-aligns-with-nist-on-authentication-guidelines ?

In XCI-30 we're simply using whatever XSEDE Duo authentication methods are enabled by XSEDE. Brian will raise this Duo policy question with Sec Ops.

Can anyone who registers with XSEDE use this service, or are there additional restrictions? Does it require an active or past allocation? Does it require vetting by XSEDE staff?

Anyone with an XSEDE portal account can use it, similar to weblogin.xsede.org. There are no additional restrictions.

Are we going to add the "affiliation" attribute, and is so, how will it be populated?

No, we won't provide an affiliation attribute. Affiliation is optional according to https://refeds.org/category/research-and-scholarship, and since XSEDE is not authoritative for a person's institutional affiliation, it would not be correct for us to assert it.

Version 1.1 of https://software.xsede.org/svn/xci/activities/xci-030/trunk/Deliverables/XSEDE-InCommon-IdP-Design.pdf includes clarifications to address the above questions.

Version 1.1 of:
https://software.xsede.org/svn/xci/activities/xci-030/trunk/Deliverables/XSEDE-InCommon-IdP-Design.pdf

https://software.xsede.org/svn/xci/activities/xci-030/trunk/Deliverables/XSEDE-InCommon-IdP-Design.pdf

Please focus on these questions:

1. Does the proposed design satisfy the functional user requirements?
2. Are the protocols and interfaces selected appropriate and secure?
3. Are the interactions with other XSEDE and non-XSEDE services secure?
4. Are the services operated in a secure way and are the procedures appropriate to deal with planned and unplanned outages and unplanned incidents?

and the following solution supported scenarios:

1. user accesses a non-XSEDE inCommon service using their XSEDE InCommon username and password
2. user accesses a non-XSEDE inCommon service using an XSEDE InCommon user second factor