1   Introduction¶

The Vera C. Rubin Observatory’s Rubin Science Platform (RSP) presents three “Aspects” to its users: API, Portal, and Notebook. The API Aspect provides a set of VO service endpoints, augmented by Rubin-specific endpoints as needed, representing the user-facing science data services of the RSP. The Portal Aspect appears as a Web application (or applications) to its users, but also provides service endpoints for the interaction with or customization of Portal components. The Notebook Aspect presents a JupyterHub login and session-launching Web application, which brings the user to an instance of the JupyterLab Web application. Each of these Aspects is made available externally through Web endpoints.

The Science Platform is or will be deployed in several distinct “instances” in LSST:

• the Data Access Center at the U.S. Data Facility;
• the Chilean Data Access Center;
• the Interim Data Facility, hosted in the Google Cloud, in which three separate instances are deployed: production, integration, and development;
• a partial instance on the Summit, which will likely not have most, or any, of the VO data services;
• an integration instance for preparing updates to the Summit instance (currently hosted at NCSA);
• the Commissioning Cluster; and
• the inwardly-facing instances to support DM development at NCSA: the “lsp-stable” and “lst-int” instances.

Each instance has, in addition to the pages/URLs for its Aspects and services, a main landing page which welcomes the user to the RSP as a whole and directs them to the Aspects and to documentation on each. This is the only page which is generally available to users without authentication.

Distinct endpoints are required for each Aspect’s services in each instance. In some cases, as for IVOA services, the pattern of endpoints for an individual service may be constrained by external standards.

Within an instance, the Aspects need to be able to communicate with each other, and therefore must have knowledge of each other’s endpoints within that deployment. Even within a single Aspect, there are internal components that need to communicate with each other.

User code running in the Notebook Aspect, or in Python plugins in the Portal Aspect, or in the envisioned next-to-the-data processing component of the Data Access system, also needs to be able to communicate with RSP endpoints. Notable use cases include references to API Aspect services - e.g., TAP - from user code in a notebook, as well as references to Portal Aspect visualization services such as pushing an image to Firefly for display. We wish to provide as transparent a user interface for those references as possible, ideally providing instance-sensitive defaults. For example, we wish a user to be able to use firefly_client or afw.display from within the Notebook Aspect without being concerned about knowing the correct URL for the instance-specific Firefly server.

For these reasons, as well as for general considerations of ease of deployment and development, it is highly desirable for these inter-Aspect and intra-Aspect connections to all be “relocatable”, in the sense that all these connections can be redirected via a single instance-wide configuration parameter.

Note that the division of services into “Aspects” is primarily of pedagogical value and need not be directly reflected in the implementation. However, reflection of the existence of the Aspects in visible parts of the implementation, such as URLs displayed in a browser or in code, does reinforce the user-facing documentation and is preferable, all other things being equal.

In addition to the nominal public-facing services of the RSP, the implementation of the RSP uses additional services, some of which are also exposed externally but are not ones we highlight in the description for users of the RSP. These also need to be accommodated in any scheme. A key example is the central authentication and authorization service, which is discussed further below.

By default all RSP services will be made available via HTTPS. Exceptions may be granted after change-control review including ISO feedback if there are strong performance or other technical grounds for them.

2   URL Structure Alternatives¶

With the following substitutions:

instance_base

Base DNS name for an entire instance of the RSP

instance_stem

A stem for a hostname component of a URL, shared by all services in a single instance of the RSP

aspect

Aspect name: api, portal, or nb; optionally extensible to provide endpoints for “implementation” services such as authorization

service

URL pathname component(s) for Aspect-specific services, e.g., tap, firefly

where aspect and service are meant to be standardized names across all instances, we have considered the following alternative URL structures, with the URLs for two instances (arbitrarily called data and data-int) given for clarity.

1. https://instance_base/aspect/service, e.g., https://data.lsst.org/api/tap, https://data-int.lsst.org/api/tap
2. https://aspect.instance_base/service, e.g., https://api.data.lsst.org/tap, https://api.data-int.lsst.org/tap
3. https://service.aspect.instance_base , e.g., https://tap.api.data.lsst.org, https://tap.api.data-int.lsst.org
4. https://instance_stem-aspect.instance_base/service, e.g., https://data-api.lsst.org/tap, https://data-int-api.lsst.org/tap
5. https://instance_stem-aspect-service.instance_base, e.g., https://data-api-tap.lsst.org, https://data-int-api-tap.lsst.org

(NB: The data.lsst.org and data-int.lsst.org URLs, etc., are purely hypothetical, chosen simply to avoid using any existing concrete instance as an example.)

Note that there are additional options in which the “api” is dropped and the individual API Aspect services are simply promoted to the same level in the hierarchy as portal and nb. We do not discuss those further at this time, as we consider them somewhat less desirable, for the pedagogical reasons mentioned above.

3   Usage To Date¶

Option 1 was used for all the initial deployments at NCSA (e.g., https://lsst-lsp-stable.ncsa.illinois.edu/(aspect)), the IDF (e.g., ``https://data.lsst.cloud`), and the Summit. The security issues mentioned above were raised before these deployments began and were not considered in the original decision.

The pattern has worked well, absent that concern, and the transformation rule based on the hostname=instance mapping is embedded in a number of places in existing code. A change to Option 2, or any other one, would require identifying and modifying those rules. This should be done in a backwardly-compatible way, so that service code capable of running with an Option 2 (for example) pattern can also still be run in RSP instances using the existing Option 1 pattern. This might require some special-casing of the recognition of legacy RSP URLs, but this seems preferable to a “hard fork” of the services.

The security argument for changing the existing design and segregating the authorization service to its own hostnames appears very strong.

If we wish to make a minimal change, we could keep all other services where they are, in an Option 1 pattern, and only add a single new hostname per instance, just for the auth service, e.g., (hostname)-auth.(domain).

4   Path Forward¶

This is a matter of active discussion. The present version of this note is only intended to lay out alternative more explicitly, to facilitate a decision. The decision will be recorded here in a later release of this note.

5   Intra-Aspect Service Naming¶

In order to supply additional context, the following subsections, to be fleshed out over time, will set out the basic plans from each Aspect for the use of the pathname space below their main entry points.