Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Re: external people as group members

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Re: external people as group members

Chronological Thread 
  • From: Shilen Patel <>
  • To: Chris Hyzer <>
  • Cc: Tom Barton <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] Re: external people as group members
  • Date: Mon, 19 Apr 2010 10:35:05 -0400


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)?


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

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


Shilen Patel wrote:

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?


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


Archive powered by MHonArc 2.6.16.

Top of Page