ACCESS OnDemand Pilot Brainstorming

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).

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.   

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