Grouper Users - Open Discussion List

[Tom Barton <>]

I'll try to not rehash the perspectives already offered beyond saying 
"+1", but I will try to add two tidbits.

Tidbit #1 is that the BioMed Informatics group at Ohio State who did 
caGrid, the grid infrastructure for the national cancer research 
community in the US, also created the Subject source Bob mentioned that 
presents authenticated users as Subjects. That was part of their 
adaptation of grouper into GridGrouper, a key part of caGrid's security 
infrastructure.

Tidbit #2 is the conceptual connection that the "invitation problem" has 
with this thread. If a federated grouper instance, whatever that means 
exactly, is not open to just anyone, how do you limit who it is open to? 
Ie, how, logistically, do those so authorized go about inviting 
participants into the scene? A process that starts "out of band" and 
results in the necessary identifiers being in the necessary places so 
that the invitee can act in the federated instance is a solution to the 
invitation problem.

Tom

Chris Hyzer 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.
>
> 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"