Grouper Users - Open Discussion List

[Chris Hyzer <>]

We can make a shib authentication plugin or setting which could get other 
shib headers to make this a little easier. (so you aren't only reliant on 
getRemoteUser)

At penn we have a grouper group of people allowed to login to the UI, though 
it is also a small number of people.  If you had that control then another 
step could be to add the user to your source and UI group (and remove when 
the user is expired or done).

Also, we aren't using external users, anyone with experience?  

Regards,
Chris

> -----Original Message-----
> From: Martin van Es 
> [mailto:]
> Sent: Tuesday, February 24, 2009 10:23 AM
> To: Grouper Users Mailing List; Hans Zandbelt
> Subject: [grouper-users] Grouper and federative login
> 
> 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