Grouper Developers Forum

[Brendan Bellina <>]

On Nov 3, 2010, at 12:27 PM, Jim Fox <> wrote:

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

In the one account per person model that may be the case. At places where people have multiple local login accounts the ePPN may be based on one of them or perhaps neither of them.  

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?

What I have generally seen done when registering via email is that a unique link is provided in the email. Clicking on the link is sufficient to activate the account with appropriate privs. I imagine the same kind of mechanism could be used. 

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.

Hopefully so. Because ePTID is by definition opaque and has unique values for each relying party there should be fewer concerns with general release than with name based identifiers.

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

I don't think that is always practical. Because an ePPN change would affect all SP's ther would need to be a communication protocol established to push out the change and/or the IdP would need to communicate prior ePPNs along with current ePPN at login. And it is likely that some SP's will simply offer no support for such changes even if a communications protocol was established to notify them.  Even some very large vendors have not historically allowed account renames. 

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.

This is not clear to me. The person making the invitation certainly needs to know how to contact the individual to make the invitation, but they wouldn't need to know anything else. 

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?

Assuming a person always comes from a single IdP then I think this is a matter of coordination at the IdP. If a person comes from multiple IdPs then they probably should be in Grouper multiple times.

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

These are going to be fairly rare and when they occur can either be addressed at the IdP or can be addressed by updates in the SP as would be needed if ePPNs changed. Alternatively targeted ids could be stored at the IdP and prior targeted ids could be released along with current id. Not everyone has a database for this currently but there is direction in Shib development to make a database requirement for IdPs in order to support high availability. 

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.

I think that relying on the release of ePPN, knowing that it is name based, is going to limit adoption. uApprove may help in this regard at some point. But planning for support of a privacy preserving attribute is prudent.

My thanks to Chris for posting this. He was listening far better than I was speaking. And considering the volume of noise where we were at the time that is notable.

Regards,

Brendan