Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] external members with targeted id

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] external members with targeted id

Chronological Thread 
  • From: Peter Schober <>
  • To:
  • Subject: Re: [grouper-dev] external members with targeted id
  • Date: Tue, 7 Dec 2010 18:24:19 +0100
  • Organization: Vienna University Computer Center

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.

Archive powered by MHonArc 2.6.16.

Top of Page