Grouper Users - Open Discussion List

[Martin van Es <>]

First of all, many thanks to all who replied, you actually managed to make me 
see even more problems than I thought there were ;)

On Tuesday 24 February 2009 18:59:54 RL 'Bob' Morgan wrote:
> I heard about one Grouper deployment that created a custom Subject adapter
> that presents the currently authenticated user as a Subject, which might
> be the kind of thing you're looking for.

I don't get this. As far as I understood the Grouper UI login, the user 
should 
exist in any one of the sources and the Group rights of this Subject are used 
to authorize modifications in the UI? If not, the login fails. What would 
'presenting the currently authenticated user as a Subject' add to that?

> As Chris implies, you need to clarify what you're looking for from
> federated access.  If it's just a few well-defined federated users, then
> something static may be OK.

Ok, I realise my question was a bit short on details, so I'll try to 
elaborate 
a bit:
The federation I'm talking about would be all institutions SURFnet offers 
services for, being nearly all universities and Higher Education institutions 
in the Netherlands (1 million potential users).
The goal is to lift group-membership of any of the students out of the 
applications so that membership is "globally" (or at least at SURFnet level) 
available to any service or application offered (by SURFnet). Eg. Students 
cooperating as a Sharepoint team (yuck, I know), would exist as the same 
group 
in the media-service application, so media could be shared among the group-
members without having to recreate the group in the media-service application 
(current practice).
Members are mostly students from any university but could be mentors as well.
Ideally (current Sharepoint practice) anyone that's succesfully authenticated 
should be able to make (a limited amount of) groups. This user is then admin 
of the group and can invite others to join the group. Members should be able 
to manage their group-membership in a self-service interface (either custom 
made, or Grouper-UI).
At this moment, institutions do nothing more than IdP tasks, sending a 
minimal 
set of attributes/claims after authentication. In other words, they can not 
be 
used as a subject source in the near, or even not so near future.

Hope this clarifies the SURFnet situation a bit.

So for Subject existance: a custom UI could take care of the necessary 
bootstrap provisioning. I'm just not quite sure how and what right now 
(should 
invitees be provisioned at invitation time, or accepting time, how do we 
deprovision?)

Regards,
Martin van Es