Status on the operability of the PDAC components after the move
Are the labels and taints working correctly?
Ensure that separate lsst-pdac and lsst-lspdev Portal Aspect instances really work (or at least that the plan to get there is understood)
Same for the Notebook Aspect (requires running a second JupyterHub?)
What is the schedule for the hostname changes (to lsst-lsp-int and lsst-lsp-stable), the acquisition of certs, and the availability of CNAMEs for the old names?
Update on the rights-checking API work (JIRA ticket?)
Update on the design for token acquisition (OAuth2 proxy?) and perhaps on a prototype
Understanding the "login experience" for an integrated LSP deployment
All
We need to understand the single-sign-on experience for people who are working cross-aspect. Today's discussion is meant to lead in very short order to an initial cut at this for the integrated LSP deployments on the merged Kubernetes Commons. (This picture will surely evolve over time.) Issues to be covered (now or in the future):
Is there a single login page for all Aspects? Does this replace the existing JupyterHub login page?
Do we have true single-sign-on? I.e., if someone logs in starting from the Portal, and they then try to get to the Notebook Aspect, are they already authenticated?
When is the NCSA two-factor authentication triggered? What happens when someone logs in with non-NCSA credentials?
How does this work when the Firefly JupyterLab extension is used to launch Firefly? Can we ensure that the Firefly session that's created inherits the authentication of the JupyterLab instance from which it was launched?
Can/should all this be done with an authentication proxy that intercepts all accesses to any of the endpoints of an LSP instance?
What is the interface that allows remote users to obtain a token that they can use to access the API Aspect (DAX / IVOA services) directly using network / programmatic APIs? Using TOPCAT?