(r23) GMSRFC < IVOA

IVOA Web>IvoaGridAndWebServices>SecurityHome>Authorization>GMSRFC (revision 23) (raw view)~~EditAttach~~
---+ Group Membership Service: Request for Comments

<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

Public discussion page for the IVOA GMS 1.0 Proposed Recommendation.

The original PR for the GMS Specification can be found at:
   * <a target="_blank" href="https://ivoa.net/documents/GMS/index.html">PR-GMS-1.0-20210609</a>
The updated __draft__ GMS Specification (with some RFC points addressed) can be found on the github CI build:
   * <a target="_blank" href="https://github.com/ivoa-std/GMS/releases/download/auto-pdf-preview/GMS-draft.pdf">GMS-draft.pdf</a>
<span style="font-family: "><span style="white-space: pre;"> </span></span>

---++ 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.<br />- Service and API: https://ws-cadc.canfar.net/ac <br />- Source: https://github.com/opencadc/ac

   * registered the CADC GMS service at 2021-10-29T18:00:00 with the very imaginative resource identifier <strong>ivo://cadc.nrc.ca/gms </strong>-- IVOA.PatrickDowler - 2021-10-29
   * registered the IA2 GMS service, IVOID set to *ivo://ia2.inaf.it/gms*. Available in full registries as of today, 2021-11-12 -- IVOA.MarcoMolinaro

---++ 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. -- IVOA.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:

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

   * Done. -- IVOA.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/). -- IVOA.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." -- IVOA.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. -- IVOA.BrianMajor - 2021-10-25
   * As Pat mentions above, this is done for the CADC GMS service. I'm looking into whether the INAF service has been registered. The CADC resource ID is: ivo://cadc.nrc.ca/gms -- IVOA.BrianMajor - 2021-11-02
(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. -- IVOA.BrianMajor - 2021-10-25
-- IVOA.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/][https://refeds.org]] or [[https://fim4r.org/][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. -- IVOA.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? -- IVOA.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. -- IVOA.BrianMajor - 2021-10-25
-- IVOA.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

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

<div dir="ltr">1. Group Name.</div> <div dir="ltr">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.</div> <div dir="ltr">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)?</div> <div dir="ltr">

   * Thanks Adrian. The CADC implementation does impose restrictions on the group name: The are case sensitive and allow alphanumerics and the characters "-", ".", "_", and "~". How does this sound? -- IVOA.BrianMajor - 2021-11-02
   * I've created a github issue for this: https://github.com/ivoa-std/GMS/issues/11
</div> <div dir="ltr">2. Group Identifier uniqueness.</div> <div dir="ltr">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.</div> <div dir="ltr">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).</div> <div dir="ltr">
   * Right, a good point. I will add this but at this time is still TBD. -- IVOA.BrianMajor - 2021-11-02
   * I've created a github issue for this: https://github.com/ivoa-std/GMS/issues/12
</div> <div dir="ltr">3. GMS availability</div> <div dir="ltr">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 (<a rel="nofollow" target="_blank" href="https://www.ivoa.net/documents/VOResource/20180625/REC-VOResource-1.1.html">VOResource: an XML Encoding Schema for Resource Metadata</a>) allows each service to define and use mirror locations (mirrorURL) to maximize their availability.</div>

   * I've added a bit of text around the caching of registry lookups as suggested by Markus. This is related so perhaps a dedicated paragraph is required. I'll rework this but at this time it is still TBD. -- IVOA.BrianMajor - 2021-11-02
   * I've created a github issue for this: https://github.com/ivoa-std/GMS/issues/13
-- IVOA.AdrianDamian - 2021-10-29
---+++ Data Access Layer Working Group

The spec is well written and conveys the requirements clearly. We have two minor edits:
   1 On p10, the citation for RFC 7234 is unknown.
   1 sec.3.1, p.11: typo (right parenthesis without a left one): "[...] must end with a newline as a CRLF 1**)**."
-- IVOA.JamesDempsey - 2021-12-20

-- IVOA.GregoryMantelet - 2021-12-20

Thanks James and Gregory. I have fixed the parenthesis typo and am working on updating the bibliography in github so that the citation resolves.

-- IVOA.BrianMajor - 2022-01-07
---+++ Data Model Working Group

Although this topic is a bit far from the DM business, I've a few comments or questions. Since none is critical, text modifications are left to the authors' appreciation.
   * Section 1 : The standard is named <em>Group Membership Service </em>but there is no mention what groups are in section 1. This section could relate to individuals as well. The reader has to reach section 2 to see that concept presented.
   * P5 Section 1.3: A few words telling who or what is usualy _in charge of granting and revoking of access_ would clarify the scope of the standard
   * P6 Section 1.4: I really appreciate that glossary! This should be an example for all of us.
   * P8 section 2.2: It is said that <em>With the help of an IVOA Registry, the system has all the information. </em>This is an understatement<em>. </em>In my understanding, group IDs, based on IVOID, need the registry to be resolved; they would be useless otherwise.
   * P8 section 2.2: 3 criteria are given to resolve group IDs (ivoid, standard_id and intf_role), as the text explictely mentions RegTAP, it would be nice to mention the table they come from in the bullet list. I'm speaking with the hat of one guy developping a registry explorer.
   * P9 section 2.2: The caching issue tackles with the concern of the validity period which is an important point. That would justify to have a dedicated (sub)subsection.
   * P10 section 3.1: I&rsquo;m a bit confused with the concept of _calling user_, is that the service or the resource with a restricted access and which operates the authentication or is that the user connecting that service? Clients using this standard are actally servers, this may lose more than one reader. In my opinion, a flow chart would help to clarify the roles of the different stakholders.
   * P13 section 3.3 : The second half of the section tells why a super-user role has been discard from the standard. I'm wondering whether a normative section is a good place for such a justification. It should be reduced at least.
   * P14 section 4: Typo: correpond%RED%e%ENDCOLOR%s -&gt; corresponds
Approved

-- IVOA.LaurentMichel - 2022-01-05

Thanks Laurent, good feedback. I've incorporated most of your comments into the pull request below. I've reduced the text on the super-user role to a few sentences in a paragraph.<br /><br /> https://github.com/ivoa-std/GMS/pull/22

-- IVOA.BrianMajor - 2022-01-07
---+++ Grid & Web Services Working Group

This standard is particularly important in the echosystem of the different standards and services pomoted by the GWS. It is finally addressing the Authorization problem.

As all the comments from the other WGs has been addressed I think we can approve it.

-- IVOA.GiulianoTaffoni - 2022-01-22
---+++ Registry Working Group

Given the registered reference implementations and standard registry entry in github (https://github.com/ivoa-std/GMS/blob/master/GMS.vor), approved.

Minor copyediting in sec 3.1:<br />"Because GMS is most useful to services with proprietary (not users themselves)" .... proprietary _resources?_

"If an authenticated user could not be identitfied", typo "<em>identified</em>"

-- IVOA.TheresaDower - 2021-11-16

   * Thanks Theresa, I've fixed the typos. -- IVOA.BrianMajor - 2021-11-19
---+++ 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...

   * Thanks Markus. Registry entries: 
      * CADC: ivo://cadc.nrc.ca/gms
      * INAF: ivo://ia2.inaf.it/gms
-- IVOA.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.

<span style="background-color: transparent;">Section 3.3 "GMS and Credential Delegation" contains more text describing what was <em>not </em>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.</span>

<span style="background-color: transparent;">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.</span>

   * Thanks (Baptiste?). I've make that suggested change. -- IVOA.BrianMajor - 2021-11-02
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..."
Many thanks for the detailed read. I've corrected these typos. -- IVOA.BrianMajor - 2021-11-02

---+++ 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?
-- IVOA.MarkTaylor - 2021-09-22

Thanks Mark, I've made these corrections. -- IVOA.BrianMajor - 2021-11-02
---+++ Standards and Processes Committee

---++ <a name="TCG_Vote_Vote_start_date_Vote_en"></a> 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 | * | | | |
| <nop>StdProc | | | | |

<!--</p> -->
Topic revision: r23 - 2022-01-22 - GiulianoTaffoni
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema