Extensive discussion of the rights-checking API proposed by Unknown User (xiuqin) at the LSP Workshop and further discussed at a recent LSP Integration & PDAC (LSPIP) meeting.
Rights such as "may use the Notebook Aspect", "may use the Portal Aspect", etc. will be modeled as membership of corresponding LDAP groups.
This check must be made by each Aspect at the time the user first encounters it, e.g., in a fresh browser session. The check could be performed by Aspect-specific code knowing the appropriate LDAP group name and looking in the group list in the user's OAuth2 identity token for this group. However, this requires Aspect code to know the site-specific LDAP group name.
It is expected to be helpful to the portability / relocatability of the implementation of the LSP components for the "magic string" that the Aspect needs to know, in order to perform the correct check, to be site-independent, representing just the site-independent abstract concept of, e.g., "may use the Portal Aspect".
The recent LSPIP meeting reached a consensus that this would be done through a RESTful network API, in preference to the provision of language-specific APIs, which would have been needed in at least Java, JavaScript, and Python.
Gregory Dubois-Felsmann proposed, to move things forward, adopting a portion of the syntax of the proposed IVOA Group Membership Service (see the recent Working Draft, specifically Section 4.1) for this API:
Concretely: GET /search/{group}
For our purposes, we will consider the "group name" to be a "virtual group" with a site-independent name (see below) which the rights-checking service knows how to map to an actual LDAP group name. We are not at this time anticipating using the proposed rights-checking API service to check for membership in LDAP groups representing collaborations or otherwise as a general LDAP-querying service.
The API indicates the holding (non-holding) of the tested right (i.e., membership (non-membership) of the associated LDAP group) with HTTP status codes 200 (OK) or 403 (Forbidden), respectively. This makes for a very simple test in the Aspect-specific code that invokes it.
The API must accept an OAuth2 identity token in its header, and the user in question is determined by inspection of the token; we do not at this time propose using the optional user= or principal= parameters of the IVOA GMS.
Most likely the membership of the desired right-representing LDAP group will be determined by a simple inspection of the group list in the identity token, but this is an implementation detail.
We do not at this time propose implementing the GMS's GET /search method (with no group name supplied) for obtaining a list of groups. However, it's not difficult to see ways in which this might be useful, and it's a possibility for future work.
The endpoint for this service will be under the common hostname for all the components of an instance of the LSP, and each LSP instance will have its own instance of this service, located under the "/api" branch of the pathname space.
Therefore, for instance, the "lspdev" (lsst-lspdev.ncsa.illinois.edu) and "PDAC" (lsst-pdac.ncsa.illinois.edu) instances will have separate rights-checking services.
For the sake of concreteness, the proposed endpoint is https://{instance-DNS-name}/api/lsp-rights/search/{virtual-group}
Virtual group names "portal-x" and "nb-x" for "may use the Portal" (respectively, "Notebook") are proposed, with the strings derived from the previously agreed pathname prefix for the Aspect and from the notion that "use" is an execute-like right (as opposed to, say, "read" or "write").
Brian Van Klaveren will include these names and others of relevance to the LSP design in an update to DMTN-094.