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.
We will not, at this time, make a public claim that our rights-checking service "is" an IVOA GMS, in view of the limited scope above, but we may discuss this work in the appropriate IVOA mailing list and/or present it at the next InterOp.
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.
It is expected that the Aspect implementation groups will, as an additional investment in future flexibility, embed these names (e.g., "portal_x" in the Portal implementation) in configuration files and not in the source code itself.
Fritz Mueller bravely accepted the (small, we believe) upscope of implementing this service and indicated that the development of a prototype version could be undertaken in December.
Fritz Mueller will create epic/story ticket(s) as appropriate to represent this work in the S19 cycle.
It is intended that the instance-specific, site-specific mapping of the instance-independent rights-representing virtual groups to actual LDAP groups will be set out in a config file for this service.
Note that the implementation of Phase 1 authorization in the Portal is blocked on this work.
It is intended that the rights-checking service be used by the Notebook Aspect as well. As there is an existing implementation of authorization-checking in the Jellybean code, which would have to be migrated to this design, and as there was no developer representation from that group at this LSPIP meeting:
Adam Thornton and others, as appropriate, should look at this design and comment ASAP, and, if possible, report at the LSP Integration & PDAC meeting.
We asked Loi Ly about any other remaining blockers for implementation in the Portal of the Phase 1 authentication and authorization plan.
He reminded us that the question is still open of the provision of an "OAuth2 proxy" to handle some of the details of the complex series of redirections and other transactions involved in using CILogon to obtain, ultimately, the needed tokens. (The alternative being making each Aspect responsible for implementing this logic.)
Kian-Tat Lim and Brian Van Klaveren promised to provide a concrete specification by the next LSPIP meeting on of what the design is in this respect, and
Brian Van Klaveren retains the action of providing at least a prototype implementation in the near future. (On we will revisit the schedule for that.)