Grouper Users - Open Discussion List

[Chris Hyzer <>]

> 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.

This is a good idea and would not be hard to implement if we don't know where 
it is.

> That system also lets any id (local or
> federated) be entered as a group member without doing any checking
> against
> a subject store, so we're thinking about how Grouper might support ad-
> hoc
> entry of federated ids as members.

This type of source (everything=ok) also sounds like it would be very 
useful... and easy to create.

Here is a related anecdote... To get access to Penn's grouper ldap, a 
kerberos principal needs to be added to our custom source, and added to a 
group in grouper.

To lower the barrier for entry, we have a self provisioning application where 
an authenticated penn faculty or staff member can just type in any Kerberos 
principal, contact info, and a reason, and that Kerberos principal will be 
loaded, and able access LDAP.  Then this transaction is emailed to the 
grouper admins (so they can passively monitor it).

Also, I might mention that Penn has integrated with the grouper UI via a 
servlet filter which does Penn single signon.  So if you wanted some logic 
when a new member logs in, you can make a servlet filter and do this.

Anyways, just though I would mention kind of a hybrid of a closed-static 
list, and a free for all... self service with passive notifications and 
auditing.

Finally, I wonder if the user population using someone's grouper is so 
diverse and potentially untrusted, if the default permissions in 
grouper.properites for READ and LIST for new groups should not be 
grouper-all, but rather just the owner can see the group... (until it is 
opened up)

Regards,
Chris

> -----Original Message-----
> From: RL 'Bob' Morgan 
> [mailto:]
> Sent: Tuesday, February 24, 2009 1:00 PM
> To: Martin van Es
> Cc: Grouper Users Mailing List; Hans Zandbelt
> Subject: Re: [grouper-users] Grouper and federative login
> 
> 
> > Anybody any experience using Grouper in a Shibbolized (or other
> > federatative protocol) environment that could comment on this?
> 
> As Peter says, SAML per se is neutral about what sort of thing, if any,
> is
> sent by IdPs and interpreted by SPs as the traditional "username".
> This
> is because SAML originally was driven by products used in bilateral
> corporate deployments where they just made something up for the
> purpose.
> Those of us promoting federations
> (http://wiki.rediris.es/tf-emc2/index.php/Federations) have dealt with
> issues like creating a common multi-institution username space at the
> federation level.  Eg the US InCommon federation manages "scopes" as
> used
> in eduPerson-defined scoped attributes, primarily
> eduPersonPrincipalName
> and eduPersonTargetedId, so that each IdP has a defined set of scopes
> it
> can assert (usually just one, eg "washington.edu" for the University of
> Washington IdP, so my EPPN is 
> "").
>   I think
> other
> federations have done this also, or something like it.  If you're not
> operating in a federation context then things are wide open.
> 
> 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.
> 
> 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.
> 
> At UW our Grouper-like group-management UI permits access by any of our
> 400K UW NetIDs, more or less.  It uses Shib for authn so theoretically
> could be extended to any InCommon Federation user (many millions).
> Would
> that imply a need to manage a list of who can authenticate, or would it
> be
> OK to let any of those millions in (as we do with our federated wiki)?
> Not clear at this point.  That system also lets any id (local or
> federated) be entered as a group member without doing any checking
> against
> a subject store, so we're thinking about how Grouper might support ad-
> hoc
> entry of federated ids as members.
> 
> So you might want to step back and think about what you're trying to
> accomplish with what community regarding Grouper.
> 
>   - RL "Bob"