Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Grouper and federative login

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Grouper and federative login


Chronological Thread 
  • From: Martin van Es <>
  • To: Grouper Users Mailing List <>
  • Cc: Hans Zandbelt <>
  • Subject: Re: [grouper-users] Grouper and federative login
  • Date: Wed, 25 Feb 2009 13:59:57 +0100

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






Archive powered by MHonArc 2.6.16.

Top of Page