Grouper Users - Open Discussion List

[Chris Hyzer <>]

Ive been thinking this over, and here are some issues to ponder:

1. If you have a source that finds the logged in user, then if you add 
yourself to a group, and someone else is logged in, then you will be 
unresolvable to them

        - Mitigation: is to be able to mark sources and neverUnresolvable.  
And we need to do more testing with grouper and unresolvable subjects (there 
are still some issues out there when groups have unresolvable members)

2. If you have sources like these two which are not populated in ldap, then 
wont ldappc (or some hook), need to add the subject to ldap before 
provisioning the memberships?  And ldappc doesn't currently do that (another 
reason Penn has our self serve app)

        - Mitigation: add more subject utilities into grouper or subject API?
        
3. If you have a source which finds anyone, then if you search for a 
subjectId which exists in another source, then wont you get a 
subjectNotUniqueException?  Same problem if the logged in user is in another 
source.

        - Mitigation: have the ability to mark a source as lastResort, so it 
checks other sources first, then if none found, checks the lastResort one

4. Its hard to know if you are misspelling a subjectId when adding someone to 
a group, if there is no subject metadata... perhaps sort of like how when we 
had to log in to the Paccman site for Steveo to assign our permissions... 

        - I guess it is something to live with, unless Grouper keeps a store 
of attributes that could be attached to external users.  Or there is a 
standard for web service sources for attribute lookup... :)

5. When people change external id's, they will not have the same memberships. 
 This is the same for changing internal id's, though I thought I would 
mention.

        - People would need to contact the grouper admin so that a 
MemberChangeSubject command could be issued

Regards,
Chris



> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Tuesday, February 24, 2009 4:52 PM
> To: Martin van Es
> Cc: Chris Hyzer; RL 'Bob' Morgan; Grouper Users Mailing List; Hans
> Zandbelt
> Subject: Re: [grouper-users] Grouper and federative login
> 
> 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"
> >