COmanage Developers List

[Niels van Dijk <>]

Hi all,

As we are working towards rolling out a national collab environment, it
is clear to us that this needs to be internationally 'enabled' to
provide international collab usefullness for our users. This seems also
true for any sizable VO platform.

The notion of being internationally enabled raises some intresting
issues, both on the federation identity part as on the groups part ;)

For the latter we are wondering how far our current Grouper setup will
work. I'd like to discuss 2 issues:
1) GUID nameing
2) Service discoverability

@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:

attribute name: guid
description: a globally unique identifier for the group that is never
reassigned or revoked.

The 'never reassigned or revoked' is something we could technically
manage, but the 'globally unique' part might be a bit more tricky. Take
e.g. the example in the same document:

Namespace example 2: "uofc:bsd"
stem: uofc
extension: bsd
name: uofc:bsd
displayExtension: Biological Sciences Division
displayName: University of Chicago:Biological Sciences Division

I note that in this example there is no 'edu' or 'us' prefix, so I
assume it is assumed that 'uofc' will be globally unique?
A 4 letter abbreviation may not suffice here I feel, what if the
University of Calgary (really, they also use 'uofc' and have a
'Biological Sciences Department') also starts providing group relations?

Within SURFnet, we currently use something like:
nl:surfnet:services:surfnetlabs

This sort of fixes the the earlier problem by adding the nl prefix. For
chicago and Calgary that might look like:
edu:uofc:bsd or perhaps us:uofc:bsd for Chicago
and
ca:uofc:bsd for Calgary

So, would such a setup work internationally?

Additionally I was wondering if the GUID should not take the form of a
URN, so something like:
urn:surfnet.nl:services:surfnetlabs, which might be more in line with
attribute schemas. This might especially become interesting when a VO
spans multiple countries, although in that case they will most likely
still have som sort of unique URL that could be used as an identifier,
something like: urn:clarin.eu:groupname
Also is there perhaps a need to define a eduGroup schema?

@2: discoverability
Second question is on the discoverability of a Grouper or other group
provider.

In many of the usecases the SP that requires group information will need
additional group information after a user has logged in, e.g. the
displayname of the group, the other members, etc.
Also SAML assertions do not seem a very suited mechanism to transport a
large amount of group data. The Grouper Webservice API is well suited
for this, but how does this SP know where to go in case it belongs to
multiple federations of perhaps multiple VOs?

We could imagine a Group WAYF functionality in which case the SP asks
the user to choose a group provider from a preconfigured list on the SP
side, this may however not be very userfriendly (and not very admin
-friendly either!).

Another possible solution could be the addition of a (SAML) attribute by
for example a VO platform which lists the available group services for
that VO. This seems like a cleaner and more flexible setup than the
first one, as now the VO is not depended any more on information stored
at the SP to work properly (assuming the SP implements this
functionality of course).

Something like:
urn:mace:dir:attribute-def:groupProvider -> url:www.surfteams.nl
and we could then also add:
urn:mace:dir:attribute-def:groupProviderApi -> urn:grouperws-1.4.2
or
urn:mace:dir:attribute-def:groupProviderApi -> urn:opensocial-0.9
(note I did not put any effort in providing semantically correct URNs,
this is just for example)

The latter proposal would dramatically reduce the amount of group data
that needs to be transferred during the SAML assertion, and allow for a
more flexible, perhaps almost dynamic, API discovery for exchanging
group attributes. Would such a setup work?

I'd be very interested in your comments and suggestions!

regards,
Niels


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