Globus OAuth SSH meeting

4 posts / 0 new
Last post
Globus OAuth SSH meeting

Meeting held 2018-05-24 that is driving the need to implement OAuth identity mappings.

Jason Alt wrote:

I wanted to share some information on where we are to make sure we are in sync: https://docs.google.com/document/d/1gvgBnv_CXDBZ9SAjqWWFJKGvaOyOxvD9tIc5u9RED_c/edit?usp=sharing. There's a lot of background information in that document but ultimately, it's the account portion (bolded as 'discussion') at the end of the document that is the crux of the meeting. 

Jason

Delivery Effort Stage: 

#1 question for me is: can we find an approach that works for both Globus SSH and Globus Transfer rather than just solving it for Globus SSH today and waiting to solve it for OAuth-based Globus Transfer some time later?

-Jim

You are right, both product lines should make use of the same information. There are similarities with our account mappings that we are baking into SSH and GCSv5. SSH requires the information client-side, GCSv5 will require it server-side. Perhaps there is an Xsede use case for Transfer that I'm not aware of? 

Takeaways from that meeting:

  • Globus is preparing a beta service with gridmap-like functionality (plus IdP suffix mapping). The initial plan for Xsede is to generate oauth grid map files for use with SSH.
  • Globus is working on a callout mechanism for account mapping that can be extended (by XSEDE) for XCDB. I (Jason) requested any public interface information for XCDB to help stir the design of the callout mechanism. (This step is not in the initial beta).
  • All of these mapping schemes are planned to be consistent between GCSv5.x and SSH.
  • XSEDE is interested in using 'account discovery' which requires the mapping to occur only on the server side, the client (globus-ssh) can query available accounts via "globus-ssh -l globus-mapping <xsede ssh service>", the client stores the account locally. This occurs once and is transparent to the user. (This step is not in the initial beta)

Next steps are to discuss consent and login flows for users and the user experience around that. Finally, XSEDE will want a LOA (level of assurance) setting to reasonably ensure that the user is THE user (mimic hub policy to login/logout daily, LOA will mimic proxy expiration, likely via forced re authentication of the user on some cadence). All of this is planned post initial beta.

Log in to post comments