International Virtual Observatory Alliance

Difference: GMSRFC (11 vs. 12)

Revision 122021-10-29 - AdrianDamian

META TOPICPARENT	name="Authorization"

Group Membership Service: Request for Comments

<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Public discussion page for the IVOA GMS 1.0 Proposed Recommendation.

The latest version of the GMS Specification can be found at:

PR-GMS-1.0-20210609

Reference Implementations

IA2 group at INAF developed a GMS implementation based on OAuth2 access tokens (JWT). The implementation is currently used by several astronomical portals for authorizing resource access. In addition to the standard search API some additional endpoints and a UI have been developed. The service is written in Java and source code is available at https://www.ict.inaf.it/gitlab/ia2/ia2-gms
The CADC has been operating a GMS service since 2013. It is a critical component in the architecture as all authorization decisions are based on group membership. It is implemented with an LDAP back-end. The service has extended the GMS API to include mechanisms to allow users to create and manage their own groups and memberships.
- Service and API: https://ws-cadc.canfar.net/ac
- Source: https://github.com/opencadc/ac

Comments from IVOA community members

Markus Demleitner

(1) p8 "(as is explained in the IVOA Identifiers document)". Umm, no, IVOA Identifiers doesn't really tell you how to resolve an ivoid. The document that currently comes closest to doing so is actually RegTAP. But in fact, "resolving an IVOID" can mean any number of things, so it's really had to say where one learns how to do that in general. Now, since your document explains how to do that resolution for your use case just a page further down, I'd say all you need to say here is "as outlined below".

Consequently, "lookup the document associated with .. in the registry; or, issue a RegTAP query" is not an alternative. The RegTAP query is a form (the primary form, I would say) of Registry lookup. Hence, I'd replace the entire paragraph "There are two ways...in the where clause" with "To obtain the access URI for a GMS service, a Registry query is performed. Using RegTAP, one uses the following three constraints:"

Thanks, I've changed the paragraph to be as you suggest. -- BrianMajor - 2021-10-25

(2) p8 I think italicising RegTAP column names as you do when first mentioning security_method_id, is a good idea. I'd vote for doing this for ivoid, standard_id, and intf_role in the bullet points above, too, and then for all column references in the running text that follows. Alternatively, you may want to follow RegTAP's markup for "things in RegTAP", which defines:

\definecolor{rtcolor}{rgb}{0.15,0.4,0.3} \newcommand{\rtent}[1]{\texttt{\color{rtcolor} #1}}

Done. -- BrianMajor - 2021-10-25

(3) Your standard points to a deficiency in Registry I've long wanted to fix but that's still open: RegTAP doesn't tell you where you can run the query on p.9; while once you have a RegTAP service, you can discover more, there's no initial, documented, "master RegTAP" where you could start. The only thing that approaches being well-defined is "To find a RegTAP service to execute this query on, consult https://www.rofr.net" or so. While that's certainly not beautiful, I'd say people will be grateful for a footnote to that effect.

Good suggestion. Done (but used http://rofr.ivoa.net/). -- BrianMajor - 2021-10-25

(4) I think you should say a word or two on how often the Registry queries should be re-performed. I could imagine that several long-running services would do such a query on startup and then simply re-use the access URL they found for while they're running unless you advise against that (which I think you should). Saying something like "invalidate cached access URLs after 10 minutes | 1 hour | 1 day | 1 month" would help giving people realistic expectations as to how fast changes made will propagate once they're in the Registry. A similar consideration might apply to the caching mentioned in Example 3; it says there that caching can occur for the lifetime of a request, which is probably the lowest sensible value. If longer caching of GMS results shouldn't happen, I think you should explicitly state that somewhere.

A very good point and something that seems to be coming up frequently. Where to point tools that need to do registry lookups on a transactional basis? Anyhow, I've added a short paragraph at the end of section on resolving group identifers: "Clients and services that will require frequent lookups of GMS services should strongly consider caching a map of group identifiers keys to access URLs values. Access URLs probably change very infrequently. Caching would reduce the traffic on the RegTap services and improve the performance of authorization checks in general." -- BrianMajor - 2021-10-25

(5) I'd be a lot more relaxed if there were at least one service with an appropriate standard_id had actually made it to the Registry. Actually, given previous experiences, I'd appreciate (and write, if you want), a section on "Registering Group Membership Services". At this point it would probably just show an untyped capability with a ParamHTTP interface, but that's only obvious to Registry buffs, and we ought to tell others lest we get all kinds of incompatible patterns that will lock us in later.

Working on that, correspondence has been in github. -- BrianMajor - 2021-10-25

(6) I've not thought deeply about that, but p.10's "If the user cannot be identified from the call because they have not authenticated (the request is anonymous), the service must respond with HTTP 401 (Unauthorized)" made me think if there's not a case for "figure out the group(s) the anonymous user is part of". Is there? Or would the 200 instead of the 401 hide common errors?

Hmm, intersting but I can't think of a use for an anonymous group. If the concept were to exist, it would probably be on the client side as it has intimate knowledge of the authorization decision being made. -- BrianMajor - 2021-10-25

-- MarkusDemleitner - 2021-09-13

Carlo Zwölf

(1) A reference to- or comparison with other initiatives dealing with similar issues/use cases (like https://refeds.org or https://fim4r.org, which -at least at EU level- are more integrated with what is going on in EOSC) would be welcome

Thanks, I like this idea and anticipate other will ask the same. -- BrianMajor - 2021-10-25 I've created an issue for it here: https://github.com/ivoa-std/GMS/issues/8

(2) In paragraph 3.1 it is not really clear how the authentication happens for the user who is submitting a query (It is said : "It is the authenticated user (the user making the REST call...")). How the user is authenticated before invoking the group service? This should be part of the GSM-API description. (e.g. should I post the certificate in the query??). Something is explained after in the examples, but some more precisions should be put at this level.

The next sentence "Users' identity is determined by one of the authentication mechanisms described in the IVOA Single-Sign-On Profile." is the attempt to defer the details of authentication to the VO SSO specification, as I thought it important not to include the same information in two places. Given this do you have a suggestion on how to improve the clairty? -- BrianMajor - 2021-10-25

(3) I am confused about dealing with conflicting information: if service GSM-A tells that user1 is in group1 and service GSM-B tells that user1 is not in group1, who should I believe? How the user may know what GSM service a data-extraction service will invoke? Who does know exactly which service should be queried? How the information are synched between GSM servers?

A group is not scoped beyond an instance of a GMS service. So, group1 in GMS-A is not the same group as group1 in GMS-B. The 'authority' part of the GMS ID is included, and the two services will have different authorities. -- BrianMajor - 2021-10-25

-- CarloMariaZwoelf - 2021-09-14

Comments from TCG members during RFC period: 2021-08-25 - 2021-09-30

TCG Chair & Vice Chair ( _Janet Evans, Marco Molinaro )

Applications Working Group

Added:

>
>

The document looks good over all. Here are some aspects that we feel could strenghten it.

1. Group Name.

The document should probably provide some guidance/conventions regarding the selection of Group Name. It's true that the group identifier is an IVOID, but the spec is a bit vague in case enforcement and that can have serious consequences if some GMSs are case sensitive while others are not.

IVOID also allow a number of special characters uncoded while the rest need to be percent-encoded or utf-8 encoded. Should Group Name impose restrictions on the character set (at least to start with) so that they can be used in other contexts (OS ACLs for example)?

2. Group Identifier uniqueness.

We would like to see the importance of Group Identifier uniqueness being highlighted somewhere in the document (either in a special paragraph or part of an existing one). In a way, creating a group is like issuing a DOI: everybody might know about it but the service itself is not aware of where it is referenced from. Therefore, while a GMS might allow groups be deleted/deactivated the service should never allow the reuse of that identifier to represent a different group of users.

Imagine the following scenario: a user creates a group ("my-collaboration") so that his team can share access to private resources (data, processing facilities, etc). Later they finish the project, publish all the data and the user decides that the group is not needed anymore because all the data is public and, for convenience, they delete it from the GMS. If the GMS allows for the reuse of the Group Identifier and a different "my-collaboration" group is created, that group might inadvertently gain access to resources previously reserved for the original group (such a processing facilities).

3. GMS availability

It might be worth mentioning somewhere that GMS plays a critical role in distributed authorization check and the service needs to have very high availability. While the GMSs hosted by various institutions are independent, the IVOA VOResources spec (VOResource: an XML Encoding Schema for Resource Metadata) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.

-- AdrianDamian - 2021-10-29

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Semantics is unconcerned by the standard as far as I can see.

However, we are not quite happy with the demonstration of the reference implementations as long as these are not actually registered, because that makes us doubt existing "clients" (which, of course, are servers in this case) actually use mechanisms outlined here. Not that I doubt they'll work, but you know how there's always ugly little snags you only notices if dumb computers and not smart humans execute a spec...

-- MarkusDemleitner - 2021-09-13

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

On the whole, this standard seems reasonable.

I believe, after following some links and skimming the IVOA Identifiers standard, that I understand how the IVOID of the group identifier can be parsed to determine the single, authoritative GMS service to query, but I would be happier if someone more experienced with Groups in this context could confirm that. My beliefs are not yet convictions, I guess.

Section 3.3 "GMS and Credential Delegation" contains more text describing what was not done than what was done. I understand why, but I lose the point of the argument in the length of the text. It might be appropriate to add a sub-heading to set the "why-we-didn't" discussion apart from "what-we-did" description; or perhaps instead a firm statement that the alternative approach was considered but rejected (or not adopted, or set aside for potential future implementation, etc.) for the reasons listed.

I agree with the suggestion in Martin's point (3) - I am still finding "breadcrumbs" to be precious in coming to grips with the entirety of IVOA standards and protocols.

Minor typos:

Section 3.1, in the paragraph beginning "It is the authenticated user...": the words "of the" are repeated in the first sentence ("of the of the").
Section 3.2, Example 1, first sentence: "...request from a user read a node..." should probably be "...request from a user to read a node..."
Section 3.2, Example 1, paragraph beginning "After receiving this response, ...": "... a member of group allowed ..." should be "... a member of a group allowed..."
Section 3.2, Example 3, example group list: I suspect the intention was for "my-thrid-collaboration" to be "my-third-collaboration"
Section 3.3, second paragraph: There is an extra '.' in the parentheses: "(proxy certificate, token, etc..)"
Section A.1, third bullet: "Update examples with to match..." should be "Update examples to match..."

Theory Interest Group

Time Domain Interest Group

Operations Interest Group

Looks good to me. Apart from comments already made by others, only a couple of minor typos to add:

Sec 2.1: "a single entity than can be referenced" - should "than" read "that"?
Sec 3.1: "services with proprietary (not users themselves)" - word missing after "proprietary"?
Appendix A.1: "Update examples with to match API changes" - missing word?

-- MarkTaylor - 2021-09-22

Standards and Processes Committee

TCG Vote

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

Group	Yes	No	Abstain	Comments
TCG
Apps
DAL
DM
GWS
Registry
Semantics	*			(once there are registered GMSes that are used some A&A machinery)
DCP
Edu
KDIG
Radio
SSIG				Typos included in comments
Theory
TD
Ops	*
StdProc

<--
 -->

View topic | History: r29 < r28 < r27 < r26 | More topic actions...