Group Membership Service WD next steps

[Brian Major]

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.


>
> 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?

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20191216/8fcab620/attachment.html>