Grouper Users - Open Discussion List

[Martin van Es <>]

Hi,

I've found the following page about Customizing Authentication:
https://wiki.internet2.edu/confluence/display/GrouperWG/Customising+the+Grouper+UI#CustomisingtheGrouperUI-
authn

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 
and institution 
(user_id@institution
 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 
(=institution)?
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 
how 
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?


Regards,
Martin