Group Membership Service WD next steps

[Giuliano Taffoni]

> On 16 Dec 2019, at 20:57, Brian Major <major.brian at gmail.com> wrote:
> 
> Hi Giuliano and all,
> 
> On Thu, Dec 5, 2019 at 8:58 AM Giuliano Taffoni <giuliano.taffoni at inaf.it> wrote:
> 
> In practice, I expect that on Site A a user delegates its credential to a service that then contacts a GMS on Site B. The GMS extracts from the CDP (actually X509 based) the identity (dn) and authorizes the service to search for groups.
> That means that the GMS at site B is aware of the user identity to proceed with the authentication. Am I right?
> 
> In your example, I don't think site B needs to be aware or interpret the identity of the calling user.  It knows the user has authenticated (that's inherent with client certificates) and now only needs to ask its GMS implementation about the group memberships for the DN representing that user.  So, as long as site B trusts the user's certificate signing authority then no prior arrangements between the two sites need to be made.
>  
Ok I agree, I am not sure how this will be translated outside the x509 framework. It is now working because of the X509 chain of trust (and in the grid framework, because the users belongs to a VO).

> 
> I am a bit sceptical in implementing (or proposing ) a standard that requires a predefined trust arrangement, so method 2.
> 
> Yes, me too.  And since we haven't heard from working group about this it seems it's not likely a required use case.
> 
> Then it is not clear to me is what happens  if we keep Method 2  as it is (i.e. optional), should we provide anyway the identity and the identityType which as you said it is not part of this specific document?
> 
> Yes I would say that another standard would need to address how user identities are described.
>  
> On the other side, if we rely on CDP identity, it is mandatory to start working on a new CDP standard that provides support also for other methods than X.509. And in my opinion, this is where we should put some efforts.
> 
> So I am in favour of:
> Method 1 is mandatory and recommended and only
> Client services must implement CDP.
> We work to extend  CDP capabilities (who? :-) )
> 
> I think you're right about this, and it will allow us to move forward with the working draft.  Could you please add this to the agenda for Thursday's telecon?
> 

Yes the discussion topics will be SSO,  GMS and CDP.
well we will have one hour, a bit more, so we must go to the point and identify off line work
Regards
G.


> Cheers,
> Brian
>  
> 
> 
> > On 17 Oct 2019, at 18:54, Brian Major <major.brian at gmail.com> wrote:
> > 
> > Dear GWS,
> > 
> > At the interop in Groningen I presented the current state of the Group Membership Service (GMS) working draft.  In that presentation I explained how a decision on the inclusion of the "identity" parameter was necessary, what the important factors are to consider, and what the inclusion of the parameter would likely entail.  I'll summarize that information here.
> > 
> > We would like to hear your opinions on this so we can work toward moving this to RFC.
> > 
> > The slides explaining the situation are here:  https://wiki.ivoa.net/internal/IVOA/InterOpOct2019DAL/GMS.pdf
> > 
> > But I'll explain it again in this email so we can discuss.
> > 
> > The minimal REST API to GWS to support interoperable authorization is this:
> > 
> > GET to /gms/search  -  to get the list of groups for which "the user" is a member
> > GET to /gms/search/{groupURI} . -  check to see if "the user" is a member of the group identified by {groupURI}.
> > 
> > Where "the user" is the subject of the membership inquiry.  (referred to now as the "subject")
> > 
> > The WD describes two methods of identifying the subject:
> > 
> >     1.  From the identify of the user making the call to the API, according to one of the supported authentication mechanisms in SSO 2.0.
> >     2.  From the identity conveyed by the (currently optional) API parameters "identity" (and "identityType" -- see below [1]).
> > 
> > In the current WD, support for method 1 is mandatory and recommended for two reasons:
> > 
> >     A.  Information privacy -- who (besides the subject) should be allowed to see group membership information?  It probably should not be public information, which implies only a certain set of privileged users should be allowed to use the identity parameters (method 2).   (More on this is in the slides.)
> > 
> >     B.  Avoiding inter-institute trust arrangements -- Following reason A:  If a GMS implementation only supports method 2, the list of 'privileged users' from other institutes whom are allowed to call GMS would have to be identified and maintained.  This arrangement is essentially a trust relationship between centres.  In this scenario, a GMS client would not be able to dynamically look up a GMS service in the registry and use it without first having an agreement in place.
> > 
> > GMS is of most use by other services that have resources that are only available to members of a certain group.  Thus, to use method 1, these services must be able to act on behalf of their calling users.  This is achieved by the processes described in the Credential Delegation Protocol (CDP).  [2]
> > 
> > So, what should be the stance on these two approaches?
> > 
> > Interoperability between institutes implementing only method 2 can probably not be achieved "at runtime" (because of information privacy) without predefined trust arrangement.  Although, once in place, the standard protocol becomes useful.
> > 
> > Method 1 requires that client services of GMS employ CDP.
> > 
> > Perhaps the current state of the WD is correct?  It says:  Method 1 is mandatory and recommended.  Support for method 2 is optional.  Client services must implement CDP.
> > 
> > Finally, if method 2 remains in the WD (optional or not), the representation of identities that are to be in the 'identity' parameter would be exposed in the API and thus need to be fleshed out.  That standardization (in my opinion [3]) would need to go into a different document.  The document would describe a simple identity model, serialization, and perhaps a schema.  Thoughts on this would be appreciated as well.
> > 
> > Thanks for reading.  Regards,
> > Brian
> > 
> > 
> > [1]  If we choose to support the identity and identityType parameters they will be consolidated into a URI where the schema conveys the type of identity being described.  Something like "token:kjd87aj2ljg8lhs" or "x509:cn=user,ou-=university,c=canada".
> > 
> > [2]  Current CDP REC version 1.0 is based on X.509, but there seems to be agreement that support for OAuth2 tokens could be added in the next version.
> > 
> > [3]  The experience of building other standards has shown that it is wise to separate the model from the services so they can evolve separately.
>