Grouper Developers Forum

[Chris Hyzer <>]

Argh... I called ProtectNetwork to see what kind of support they offer, and 
they changed their policy (not sure when) and said they only release an 
authentication assertion for non-grandfathered SP's and not the EPPN by 
default unless the SP in question is registered with them which costs some 
money as a one-time cost.  The grouperdemo server is pretty new, so I don't 
know why it gets the EPPN from ProtectNetwork, maybe due to internet2, not 
sure...

Regards,
Chris

-----Original Message-----
From: Chris Hyzer 
Sent: Tuesday, December 07, 2010 12:53 PM
To: 'Peter Schober'; 

Subject: RE: [grouper-dev] external members with targeted id

Great, thanks for the info.  Grouping at the SP request level sounds great.  
I would be interested to try that out.  Does anyone know approximately what 
percentage of IdP's are at least 2.2?

Your other comments are making me think that I should expose the email 
address that the person responded to for placement in the subject 
description, since it is a vetted identifier.  The reason I didn't initially 
is that the user could have multiple vetted email addresses, however many 
they were invited by (maybe the registration screen could eventually let them 
select their preferred one).  Also, if there are external people inputted by 
other means than an invite, they might not have a vetted email address...  I 
was hoping to not require release of IdP attributes, and even if we did, the 
ProtectNetwork ones would be self entered anyways...

At Penn we will use this new part of Grouper.  Is anyone else planning on 
using it?  Let me know if so, especially so we can determine if your 
requirements will be met.

Thanks,
Chris

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Peter Schober
Sent: Tuesday, December 07, 2010 12:40 PM
To: 

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

* Peter Schober 
<>
 [2010-12-07 18:24]:
> 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>.

Since your concern seems to be with (not) requiring IdP admins to make
changes: I should have been more clear that the process above does not
involve any changes at the IdP -- only additional metadata (grouping
the entityIds) and the SP sending an adjusted authentication request.
-peter