Grouper Developers Forum

[Chris Hyzer <>]

From experience getting the Grouper external subject management module on the demo server, I have learned that central user management using shib/incommon doesn’t work easily… 

 

If you are running all applications that use Grouper in the same shib entity ID, then you can handle external users who release eptid and not eppn, though the Grouper UI will only have user entered information (with eppn at least that is vetted not to be spoofed).  If you have the subject source description showing the “identifier” which for eppn people will be the eppn, for the eptid people will show something long and opaque and is not useful for picking people.  In short, handling eptid in Grouper is not really useful right now.  It would be nice if we showed the vetted user email address instead of eptid, though that’s not how it works right now.

 

So if you have external people who are at institutions that release eppn, then they are all set.  If they do not release eppn, then you either need to:

1.       Ask the user to have their shib admin release eppn for the Grouper entity ID, *and* for all other applicable entity id’s that use that Grouper.  Shilen was saying that a regex might work, but maybe it wont be secure

2.       –or- Ask them to sign up for a free protect network account

3.       –or- Wait for uApprove

Anyways, it would have been nice if there were an opaque identifier that is the same for all entity ID’s that everyone releases by default… I guess people thought that wasn’t secure… oh well

 

Thanks,

Chris

 

 

 

From: Chris Hyzer
Sent: Thursday, November 04, 2010 12:09 AM
To: 'Jim Fox'; Grouper Dev; Keith Hazelton
Subject: RE: [grouper-dev] external members with targeted id

 

Ok, im thinking more about this:

 

1.       Invite goes to email address of external person, email has link with UUID in it

2.       Person goes to registration page hosted at Grouper UI (SP #1)

3.       Grouper associates the email address, targeted ID based on the UUID in link in email

4.       Grouper assigns that user to groups specified by inviter

5.       Person goes to application (SP #2), application looks up permissions based on targeted id

6.       Unless the IdP sent the same targeted ID, then it wont work…

I was hoping that targeted ID could be a way to include external users with no IdP configuration, but now I am not seeing how it would work since there at least two SPs involved, even for one application.  For a locked down attribute release policy, either the IdP needs to release eppn, or link the SPs of an external institution to the same targeted ID… hmm

 

 

3.       The person enters perhaps some personal information into the registration page so that they can be contacted, found in pickers,perhaps email if the application requires it.  They are assigned to the groups that the inviter wanted

> How would that assignment happen?  Where's the connection between ePTID and invitation?

 

The invitation has a UUID in it, same with link back to registration page

 

Ø  The discussion comes up at UW as to what "no restrictions" means when applied to readership of a group, although it sounds awfully obvious to me.   There is some confusion as to whether the world in "world read" means the local outfit or something like 'world'.

 

Good point.  Well, world read is constrained by who can log in to the application… i.e. would the external person be able to log in to the Grouper WS?  The admin portion of the UI?  Etc?  Each has its own ACLs, so even if world readable, it is limited to people who can use the application exposing it…  if you let externals SSO to WS or manage groups with the admin UI then they would be able to read GrouperAll readable groups.

 

Thanks!

Chris