COmanage Developers List

[Niels van Dijk <>]

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.

Thanks for your comments so far. I've learned a lot already but no clear
solution yet :( Time for the coin architecture board to make up their
mind...

regards,
Niels


On 04/09/2010 05:34 AM, Tom Barton wrote:
> Niels van Dijk wrote:
>> @1: GUID's
>> I dug up some work of TomB for the grouper spec
>> (http://middleware.internet2.edu/dir/groups/docs/draft-internet2-mace-dir-grouper-search-00.html)
>>
>> which states:
>> ...
> 
> Yikes, that's old! But we did think about global uniqueness from the
> start of the grouper project. There are two forms of (partial) support
> for this.
> 
> First is the guid, which is a uuid, hence globally unique. All grouper
> groups have them. But those aren't namespaced or in any sense resolvable
> outside of the local grouper installation.
> 
> Second is the choice of URN style naming for the "name" namespace in
> grouper. The intent was that an organization would assign an arc within
> its URN namespace for grouper groups, and the group's name could then be
> concatenated onto it to form a proper URN. Eg, the grouper group here at
> U Chicago named "uc:org:ci:tggig" would be referred to in a global
> context as
> 
>   urn:mace:uchicago.edu:ucgroups:uc:org:ci:tggig
> 
> Here, "urn:mace:uchicago.edu" is U Chicago's URN namespace, and we'd
> allocate the "ucgroups" namespace for this purpose.
> 
> RL Bob's URL alternative could be accommodated with either group
> namespace. Eg, if uc:org:ci:tggig has the guid
> 26bc60c7-0f07-4099-9e6b-2ece34db685e, that group could be referred to as
> either
> 
>     http://some.collab.int/groups/26bc60c7-0f07-4099-9e6b-2ece34db685e
> or
>     http://some.collab.int/groups/uc:org:ci:tggig
> 
> It might not be a long stretch to make this URL resolve to an object
> describing the group.
> 
> Of course, there is no support in the current grouper release for
> configuring a URN or URL prefix so that it can express names in a
> globally unique format when required. I've been waiting for the first
> real use case to show up. Maybe it just did! :-)
> 
>> @2: discoverability
>> Second question is on the discoverability of a Grouper or other group
>> provider.
>> ...
> 
> This is a much harder problem in the general case. For two reasons.
> First is the definition of the end point reference, both in terms of its
> functional api(s) as well as the infrastructure and standards with which
> to locate it. And even if that's dealt with, a runtime callback approach
> in a federated environment can run afoul of network/firewall
> configuration and policies at member sites, as well as security policy
> in the local groups implementation. So we're probably left with an
> approach along the lines Bob outlined, in which IdPs expose new
> endpoints for this purpose. They are already exposed network-wise and
> have mechanisms for enforcing security. But such IdP's would have to
> deal with Subjects like groups, roles, privs, whatever, in addition to
> security principals as they do now. Seems a lot of work.
> 
> So I suggest that we don't attempt to solve this general problem in one
> step, and focus instead on more restricted use cases, ones that might
> actually arise anytime soon. I know potentially of two such: caGrid and
> iPlant, two VOs in the US. Although I don't know either in enough detail
> yet, I suspect that they may be amenable to an approach in which the
> group services themselves function in a sort of federated way, which may
> mean that a given SP only needs to deal with a single group service
> which is able to provide the group info it needs because admins have
> configured it to do so specifically to support that relying party. No
> discovery, fewer interfaces, fewer flows, fewer apis.
> 
> Or maybe there's a user-centered, oauth style approach to this...
> 
> What use cases are you thinking about?
> 
> Tom

-- 
Niels van Dijk
Advanced Services

T: +31 302 305 337 / M: +31 651 347 657
SURFnet - PO Box 19035 - NL-3501 DA Utrecht - The Netherlands -

http://www.surfnet.nl
SURFnet - We make innovation work