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.

Review Summary

  • Concern raised about naming of the parallel hierarchy used for Globus Auth. Resolved by changing hierarchy name from "" 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 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.

Review Output Documents (Final)

Review Input Documents

Review Criteria

  • 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?


Current Date: 2024-07-20
Current Status: Closed (Design and Security Review)
Target Date Actual Date Activity Milestone
  2015-12-16 Review launch date
2016-01-08 Written feedback due (Reviewers)
2016-01-15 2016-02-19 Written response date (Review Material Developers)
2016-01-22 2016-02-19 Final approval due and completion date (Reviewers)
Review Created: 2015-12-16 11:06 am
Review Last Updated: 2016-02-19 7:15 am



If you are a reviewer, please login to sign or withdraw from this review.


  • Jim Basney
    SIGNED: 2016-02-06 16:06
  • Shane Filus
    SIGNED: 2016-02-12 13:28
  • Lee Liming
    SIGNED: 2016-02-08 11:31
  • John-Paul Navarro
    SIGNED: 2016-02-19 10:08


  • Victor Hazlewood
  • Gary Rogers
  • Scott Sakai
  • Tabitha Samuel
  • Derek Simmel
    SIGNED: 2016-01-07 11:00
  • Adam Slagell
  • Shava Smallen

Review Material Developers

Chris Koeritz
Andrew Grimshaw

Review Facilitator

John-Paul Navarro


Please post your comments using the "New topic" or "Post reply" buttons in the forum below.