Grouper Developers Forum

[Jim Fox <>]

The obvious and natural correlation between local login id and ePPN would seem to require a really good reason not to use it.  For us the subject is the ePPN (without the '@washington.edu').  

(Other comments inline)

 

Keith had mentioned supporting external members with targeted ID a while back, and I didnt really understand how that would work (Im not a shib person).

But I talked with Brendan last night, and he explained it to me again, and now I think that is something that should be on our radar.  I think it would work with my plan for external people.

 

1.       Someone invites someone by email, with the provisioning of groups on registration

2.       That person signs in to the registration page and the targeted ID goes to Grouper

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?

 

Pros of eppn

-          That is something that is not user entered non-vetted, secureto use that to assign user to groups

Just as with local login id.

 

Cons of eppn

-          If the user’s IdP does not release this by default, the user will need to work with their IdP maintainer to release that to the Grouper and application SP’s (uapprove could help once it is widely deployed)

Release of ePTID s not always guaranteed either.   uApprove will certainly help in releasing either attribute; plus name, email, and etc.

-          If eppn changes for a person, then they lose their rights until they get re-added by the application owner, or edited by the Grouper admin

The subject database will have to be updated for the new ePPN.  But this is exactly what happens when a local login id changes — the subject database is edited, by someone or something.

 

Pros of targeted ID

-          User might not need to talk to their IdP maintainers

-          Personal information is not sent to the SP

Personal information pretty much needs to be communicated or else no one knows who gets in the group.  Anonymous membership of groups is not considered in any of the use cases considered thus far.  It would appear to be a fringe application.

 

Cons of targeted ID

-          If multiple SP’s at one institution need to have the same external user in their systems (in one Grouper), then the external user’s IDP could be configured to send the same targeted ID to the multiple SPs, or the user could have multiple accounts in Grouper

Not many IdPs support same ePTID to different Service Providers.  I can think of only one.  Multiple accounts in Grouper is horrible.  How would anyone whom to invite?

-          All of the user readable attributes in grouper are entered by the user (non vetted), so once the user is in Grouper, and someone wants to put them in other groups, it seems like it would be difficult to trust finding and assigning the person without another email invite loop…

-          Some changes in setup (if the IdP or SP change in certain ways) could change the targeted Id.  That could be confusing to map the old one to the new one for the Grouper administrator…

 

Discussion?  Other considerations?

I generally think that working with external users ought to be as much like working with local users as possible.  If someone can add local subjects to groups, why not let them add ePPNs to groups, populating the subject source automatically.  If a group has opt-in privilege, maybe allow any ePPN to opt in, again populating or filling in the subject source as needed.

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

Jim