Grouper Developers Forum

[Shilen Patel <>]

Hey,

So I'm thinking there may be two classes of external people.  First are 
those that are members of an institution that's in the same federation 
as the SP (Grouper instance).  And second, those that are not.  The 
second case can be more complicated since it would involve local 
accounts, potentially some type of approval, an expiration potentially, 
etc...  It seems like you're trying to solve the first case, right?  And 
leave the second case for the IDM to handle (in Duke's case giving 
external accounts that can be used with our external IdP)?

Thanks!

-- Shilen


On 4/19/10 10:01 AM, Chris Hyzer wrote:
> To introduce, I am exploring if we want:
>
> 1. a grouper table to hold a list of external people, and a subject source 
> that reads from that table
>
> 2. a self-service screen on the grouper UI (which would be a lightweight page 
> like SimpleMembershipUpdate, doesn't even have to mention grouper, or link to 
> admin ui, etc).  So if you want to use an external person in Grouper (or in 
> your table or LDAP), then you would email the person with a link to the 
> registration page, they would login with Shib or whatever, and then enter in 
> whatever info we keep about them.  e.g. loginId, name, description, email 
> address
>
>    
> > Is there a reason to put the registration page in the grouper UI? I bet
> > that almost always the reason the external person is there has nothing
> > to do with grouper, as far as they know.
> >      
> Right, I picture it as separate from the admin ui, but running in the same 
> war.  We could also make it skinnable if we want...  :)
>
>    
> > What forms of external authN should the external registration page
> > support? SAML&  OpenID surely. Anything else?
> >      
> The Grouper UI authn is pluggable, whatever authn you setup.  I picture shib 
> as what most people will use, but you could do whatever
>
>    
> > Will local accounts be created, eg, username/password?
> >      
> I don't need or envision this, I was assuming shib.  The username is whatever 
> the authn passes to the grouper ui.
>
>    
> > I agree with a plug-in approach for provisioning registrants, or at
> > least having RDBMS&  LDAP options. How about SPML? Is that statement
> > even well-posed?
> >      
> Sure, if you want to use the page and not the JDBC source, we could have it 
> pluggable to accommodate that, or we could make two screens, a JDBC and JNDI 
> one, or spml, etc.  I don't think there will be a lot of code involved...
>
> In summary, I think this is an option for people who want something like this 
> for Grouper.  If there is a wider need, or your IDM already has it, use that 
> and integrate with grouper with another subject source pointing to the data...
>
> Thanks,
> Chris
>
> Shilen Patel wrote:
>    
> > Hey,
> >
> > Duke has been looking at doing something similar.  We currently have a
> > separate Shibboleth IdP for external people, however, right now the
> > reason for having external people isn't for groups, but we'll probably
> > want to assign group memberships in the near to mid term.  We went with
> > a separate IdP just to make sure that these people do not get into
> > applications that don't do proper authorization.  So instead if an
> > application wants to allow external people, they would have to trust
> > this external IdP.  Is this an issue you see yourself having?
> >
> > What I was thinking about doing is having some sort of registration page
> > that stores the external users' identity information in our IDM.  Then
> > we would synchronize that data to our LDAP (in a different suffix that's
> > not a child of what most people use as their base DN for searches).
> > This would allow us to store group memberships for external people in
> > LDAP and also allow us to use the built in LDAP subject source for them.
> >
> > So I'm just thinking that if I was going to use this enhancement, I
> > would want the registration page to be able to use the SPML interface
> > that our IdM provides.  So maybe the registration page can allow you to
> > plugin how to get and store the identity information for the external
> > people rather than assuming it's just a database table?
> >
> > Thanks!
> >
> > -- Shilen
> >
> >
> > On 4/16/10 6:08 PM, Chris Hyzer wrote:
> >      
> > > Here is an idea to discuss at dinner:
> > >
> > >
> > >
> > > Grouper could have another optional built in subject source for
> > > external people.  This has columns for id, name, description (maybe more).
> > >
> > >
> > >
> > > Then we have a screen in the Grouper UI where external people can sign
> > > in with shib, and add or edit their information in that table.  Then
> > > group updaters can add those external people to groups.  If they cant
> > > find the people to add, then they (or with the help of the Grouper
> > > UI), can send a link via email for those people to sign in and
> > > register, and when done, they can be added to the group.
> > >
> > >
> > >
> > > At Penn we would like to have something like comanage file sharing,
> > > but we need to quicker than it seems comanage will deliver it, and I
> > > would like to use grouper, and this seems like a useful enhancement to
> > > grouper that could be used for other purposes.
> > >
> > >
> > >
> > > If anyone knows of a good open source file sharing app (sythos and
> > > basecamp were ruled out), let me know, or if you have thoughts on the
> > > grouper enhancement let me know now or at dinner...  J
> > >
> > >
> > >
> > > Chris
> > >
> > >        
> >      
>