REVIEW-13: SDIACT-174 Integrate Genesis II WS-STS with Globus IdM - Design/Security Review

General design and security risk review for the Genesis II WS-STS integration with Globus Identity Management.

• Concern raised about naming of the parallel hierarchy used for Globus Auth. Resolved by changing hierarchy name from "globus.org" to "globus-auth".
• Concern raised about one time passwords and interaction with Globus Auth WS-STS. Not resolved, but out of scope for this activity.
• Concern raised about handling of 3rd party passwords. Resolved by restricting WS-STS to xsede.org accounts.
• Concern raised about peer authentication. Resolved via use of TLS authentication.
• Concern raised about command line parameter allowing password. Resolved by this not being advertised as a feature to the users (it is a helpful debugging aid for small bootstrapped grids).
• Concern raised about usage of Globus Auth scopes and usage of OAuth 2.0 refresh token. Resolved by incorporating scopes needed in design, and by eliminating any requirement for usage of refresh token.
• Concern raised about sending private key over wire. Resolved by refinement of design to match closer with existing xsedeLogin and do MyProxy auth as first step in client, not as later step in STS.
• Concern raised that WS-STS will need registered client identifier and secret. Resolved by incorporating that in the design.
• Concern raised about changes in SAML format or usage. Resolved by describing how SAML chains will be identical when using Globus Auth WS-STS to existing Kerberos STS case.
• Concern raised about minor points in design, plus that a diagram for existing auth process would be helpful. Resolved by addressing minor points in design doc and by including a diagram for Kerberos auth process.

https://software.xsede.org/svn/sdi/activities/sdiact-174/trunk/Plans/SDIACT-174_Design-Document_v1.1.docx

https://software.xsede.org/svn/sdi/activities/sdiact-174/trunk/Plans/SDIACT-174_Design-Document_v1.0.docx

• Criteria 1: Does WS-STS interact with Globus IdM thru the correct interfaces, in the correct sequence, and are the interactions over appropriate secure channels?

• Criteria 2: Are credentials handled, forwarded, and/or stored in a secure fashion?

• Criteria 3: Are the operational and security practices and procedures appropriate to mitigate compromises, and appropriate to deal with a compromise if it happened?