COmanage Developers List

[Tom Barton <>]

Resolving globally unique URL by a restful service should be pretty 
easy. How should the restful service decide that it should provide the 
requested info? Will the user delegate to the SP, which provides a 
corresponding token to the restful service? The delegation act would 
have to include endpoint location details.

In your use cases, does an SP ever need assertions that describe 
something other than the authenticated principal? Eg, the membership 
list of a group to which the principal is a member.

Tom

Niels van Dijk wrote:
> Hi Bob, Tom,
>
> Thanks for sharing your ideas and pointing me to interesting stuff on this.
>
> In regard to the resolving either:
> >     http://some.collab.int/groups/26bc60c7-0f07-4099-9e6b-2ece34db685e
> or
> >     http://some.collab.int/groups/uc:org:ci:tggig
> this already almost looks like a rest API call so perhaps that would be
> a nice way of solving this or Grouper?
>
> As a usecase example:
> We plan on providing a national group management service as part of
> COIN, but preferably *only* for collab over institutional borders, not
> for use in the campus domain. A group in our group service should
> therefor always contain members of at least two institutions, or should
> consist of members from one institution and users from our GuestIdP.
> From a highlevel perspective, this COIN group service is very alike a VO
> group service.
>
> Suppose now there is one service provider that offers document sharing,
> both to a campus and a COIN collab VO and the user is a member of both.
> If this user logs in to the doc sharing services, the SP needs some way
> of distinguishing between the groups that belog to the campus and the
> groups that belong to the VO. I cannot assume this SP will deal
> exculsivly with only one VO.
>
> In regard to the VO examples you mention: We have been wondering how a
> federation of group services might work, from the perspective of the
> COIN VO. We've considered a number of scenario's:
> - Copy/Sync: sync-ing a (subset of) campus group services into the COIN
> group service, e.g. nightly. We did not like that a lot, because of all
> kinds of hairiness and also we do not see how such a setup would ever
> scale on a national, let alone an international level. That is ofcouse
> unless you have very good commitment of the VO participants, as may be
> the case for iPlant and caGrid. For COIN that is typically not the case.
> - Tightly coupled: 'federate' ldaps so that the COIN group service ldap
> will query a peer in real time. Although this is already much better
> than coping everything, scaling is still an issue. Also the peer ldaps
> need to have a high availability. The only way this would work is if we
> force the peers to work with us with a standardized ldap schema. This is
> perhaps doable on a national level, but internationally? (Actually
> SURFnet tried this several years ago on a national level and this failed)
> - Loosly Coupled: let the VO query a remote group service based on some
> lightweight api, e.g. grouper WS or OpenSocial rest API. This would
> scale very well from the perspective of the VO, however this will
> require the remote party to put in some effort to provide the API, and
> the services for that.
>
> In all of the above scenarios the SP will never need to know anything
> about the fact that the collection of groups is actually the result of a
> merger. For the groups in the collection, globally unique names may be
> required, especially if their is no tight coordination between the group
> services that are consumed by the VO that assembles the group data (as
> in that case duplicate group manes might occur)
>
> A different scenario requires a bit more work from the SP. In that
> scenario, the SP is provided with pointers to group service provider(s).
> It could then take an ID for the user (e.g. provided by the federation
> login) and go out and 'shop' for the users groups.
> In this case the VO only needs to provide a pointer to remote group
> services. We currently have such a setup implemented where the SURFnet
> run SP takes the eduPersonPrincipalName and queries SURFteams to get the
> groups for that user. Currently the fact that it needs to go to
> SURFteams is fixed.
> We also tested a scenarion where indeed oAuth with user consent were
> used to query group attributes from SURFteams.