Subject: Grouper Users - Open Discussion List
- From: Martin van Es <>
- To: Grouper Users Mailing List <>, Hans Zandbelt <>
- Subject: Grouper and federative login
- Date: Tue, 24 Feb 2009 16:23:24 +0100
I've found the following page about Customizing Authentication:
Just thinking aloud:
After a successful authentication (eg Shibboleth) via some apache module, the
only link to Grouper would be getRemoteUser(). This is a single valued string
so I would have no knowledge about the institution that the user was
authenticated against, unless I come up with a way to concatenate the user_id
eg) to prevent duplicates, assuming that
a user_id cannot contain a @ in this case. This will work if we keep a shadow
database (our own source) of all subjects, with modified user_id, eg after
accepting an invitation to join a group.
If however, in some inexplicable way, we managed to convince all institutions
to cooperate and have their subject databases exposed to our future Grouper
(in some secure way) as separate sources, we would need to glue the user_id
and institution after login, have grouper authenticatie/check by passing the
result as RemoteUser, splitting it up in Grouper and feeding the 2 parts in
second variation of SubjectFinder.findByIdentifier that supports a source
Would this be a very bad idea load/security wise? My feeling says that a
shadow source is hard to maintain and will become polluted with inactive
accounts in no time, deprovisioning would be a requirement and I don't see
that's done easily in such a setup.
Anybody any experience using Grouper in a Shibbolized (or other federatative
protocol) environment that could comment on this?
- Grouper and federative login, Martin van Es, 02/24/2009
- RE: [grouper-users] Grouper and federative login, Chris Hyzer, 02/24/2009
- Re: [grouper-users] Grouper and federative login, Peter Schober, 02/24/2009
- Re: [grouper-users] Grouper and federative login, RL 'Bob' Morgan, 02/24/2009
Archive powered by MHonArc 2.6.16.