Grouper Developers Forum

[Peter Schober <>]

A few minor remarks:

* Chris Hyzer 
<>
 [2010-12-07 17:22]:
> 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.

Providing all information anyone might need to identify whether some
id represents a person one might want to add as member to a group is
not the function of an ePTId/SAML2 persistentId. Arguably this is also
valid for ePPNs (I don't know your's and you probably don't know
your's either, for the vast majority of users. "eduPersonPrinceWhat?!")

So I guess for making such decisions (and user interfaces and
applications) possible the IdP would have to release additional info,
not just a name identifier of some kind (opaque or not).

> 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

IdP admins have several ways to create and maintain policy.
Whether a regex is part of that is not relevant here, I think.

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

(I.e., don't use ePTId.) Also, with this offering /all/ data is
self-asserted (just as when only ePTId is provided by an institution).


> 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

That's possible with the Shib 2.2 IdP (I /think/ not with any earlier
releases) by using a SAML 2.0 Metadata <AffiliationDescriptor> and the
SP in question providing a reference this collection of SPs.
The IdP will then use the same entityId for all entities enumerated
by that <AffiliationDescriptor>.

But you said "...everyone releases by default" and there simply is no
"opaque identifier ... everyone releases by default" -- same/shared
entityIds or not.
-peter