COmanage Developers List

[Tom Barton <>]

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