ACCESS OnDemand Pilot Brainstorming

Owned by Alan Chalker
Last updated: Jun 27, 2022 by Sergiu Sanielevici
5 min read

Proposal for ACCESS OnDemand Pilot Proposal (90-day pilot)

  1. The goals of the pilot are to:

    1. Provide a centralized location for OnDemand activity in ACCESS to serve as a demonstration of what is possible and provide a starting point to expand over time.

    2. Link three local OnDemand deployments back to common ACCESS services to smooth the user experience.

  2. User story

    1. User authenticates to ACCESS MATCH Portal (AMP) as appropriate (e.g., CILogon).

    2. One of the top-level tabs in the AMP is labeled “ACCESS OnDemand” (or “ACCESS MATCH Tools” if the Pegasus team would also like to leverage this). Clicking on this tab brings up links to the following deployments:

      1. Bridges-2 OnDemand

      2. Expanse OnDemand

      3. Anvil OnDemand

    3. Say the user has an allocation on Bridges-2 and clicks the “Bridges OnDemand” link. The user is taken to Bridges-2 OnDemand and must authenticate as appropriate.

    4. The local OnDemand deployments have links back to the AMP and display statistics from MMS.

  3. See UI mock-up and system diagram below.

  4. Notes:

    1. This is a concept target to shoot for, not a commitment. It clearly shows the first iteration of the vision of having OnDemand at various resources leverage common ACCESS services.

    2. The underlying technology for single sign-on (OAUTH) is not in this proposal. I intentionally said, “forget that, let’s just assume the user can remember their usernames and passwords.” Any smoothing of the authentication experience through either common credentials (e.g., using the same CILogon credentials for both AMP and OnDemand) or federated authentication through OAUTH would be welcome but I consider to be independent of this pilot.

    3. The top-level AMP Tools page could also point (someday) to a central OnDemand instance that provides connections to ACCESS resources via SSH. (Terminal and hopefully SSHFS for files.). Again, let’s assume two sets of credentials at the start.

  5. First steps:

    1. Complete a “listenting tour”. Talk individually with the Expanse, Bridges-2 and Anvil teams about their OnDemand successes and struggles. See if there are common features that they’d like that we could add that would help their users.

    2. I think of “ACCESS OnDemand” to mean any OnDemand instance that is connected to (and supported by central ACCESS services). For branding, it could be “Bridges-2 OnDemand powered by ACCESS” or something like that.

    3. Create a prototype OnDemand that connects back to AMP.

    4. Talk to the MMS team about integration.

UI mock-up:

System diagram:

 

 

 

Historical context from the week of June 6:

  1. The current state of affairs

    1. Open OnDemand is a user-level web portal.  It runs within a certain authentication domain since the web server is launched as a user ID that locally interacts with systems as that user.  

    2. OnDemand is deployed in that fashion on a number of different to-be-ACCESS-allocated resources (e.g., Anvil, Expanse, Bridges-2).

    3. Under the MATCH award, we have proposed to improve the experience for ACCESS users by:

      1. Providing a consistent look-and-feel for OnDemand across resources.

      2. Enabling OnDemand installation across more ACCESS resources (reducing barriers to installation).

      3. Integrating OnDemand with ACCESS services (user documentation, user support, resource usage).

    4. XSEDE currently has a single sign-on hub allowing users to log in with their XSEDE credentials and then SSH to any resource without having to provide their corresponding local username/password for that resource.  (This relies on X.509 certificates for authentication.  The hub and each resource has to install the appropriate client and server bits of gsi-ssh.)

    5. An XSEDE team has proposed an OnDemand pilot that could potentially replace the existing single sign-on hub.  https://docs.google.com/document/d/1CGrYCgvV1pwIvnmg96Zgz3WZRBosM52wivX1M04_Idk/edit?usp=sharing

      1. The user would log in with their XSEDE credentials, be presented with a dashboard of XSEDE resources, and could click-through to the terminal app ssh’ed into the resource.  Authentication would be through OAUTH.  (This central OnDemand would need to have OAUTH-ssh installed and resource providers would have to deploy an OAUTH-enabled ssh server.)

      2. This exists only as a proposal.  There was work on a pilot (and the team indicates some resource providers are willing to test it) but it does not currently work.

      3. Lee Liming indicates that the greatest risk to this proposal is whether the security teams for the various resource providers will accept OAUTH from XSEDE/ACCESS as a secure authentication mechanism.   

  2. Potential Pilots

    1. Per-resource OnDemand Pilot

      1. Complete an assessment of OnDemand deployment posture on current XSEDE resources (see table below).

      2. Create survey of resource provider challenges/opportunities for OnDemand

      3. Put an OnDemand section somewhere on the ACCESS user portal (AUP - or AMP if it is the AUP) pointing to the Open OnDemand project and collecting links to the various local OnDemand deployments.

      4. ‘One size fits most’ apps

        1. Apps that deploy basically everywhere with no configuration whatsoever. The pilot here is to from 1-3 sites as a proof of concept.

    2. Centralized OnDemand Pilot

      1. Log in to AUP, click through to resource-level OnDemand instances without providing local credentials. This would provide a single sign-on experience for users connecting to ACCESS OnDemand deployments.

      2. Continue the XSEDE pilot leveraging OAUTH ssh and a central deployment of OnDemand.

        1. Terminal connection to all resources supporting OAUTH ssh.

        2. File viewer and editor

          1. Mounting resource-level file systems via sshfs

        3. Pros of continuing the pilot

          1. Single sign-on seems like it would be a popular feature for ACCESS.

          2. The central OnDemand instance would in theory support all ACCESS resources (that have enabled OATH ssh) and not just resources with OnDemand.

          3. Web based file manipulation and editing are very popular.

          4. While not part of the MATCH proposal, it in the spirit of the approach to “improve user experience through better tools”.

        4. Cons of continuing the pilot

          1. Operation of a central OnDemand instance would require resources to deploy, monitor and upgrade the server. This is currently not planned/budgeted in Track 2.

      3. JetStream Adapter

        1. If a centralized OnDemand does exist. Utilizing JetStream (as a pose to any on-prem site) may be a strong option.

      4. Kubernetes in JetStream.

        1. This is going to be difficult and/or little benefit over item iii above. Would also require Jetstream team to setup & offer Kuberentes with our required setup.

      5. Assumptions

        1. The AUP authenticates with OAUTH.

        2. ACCESS OAUTH token is accepted by resource provider

 

Resource

Files

Terminal

Jobs (Constructor/ Inspector)

Interactive Jobs

…

Anvil

 

 

 

 

 

Bridges-2

 

 

 

 

 

Expanse

 

 

 

 

 

…