Refeds


Subject Re: use of eduPersonEntitlement
From Keith Hazelton <hazelton@xxxxxxxxxxxxx>
Date Wed, 15 May 2013 09:40:32 -0500

On 05/15/13, Joost van Dijk  wrote:
> Hi,
> 
> That is interesting. Does this mean that Elsevier receives entitlement-values that are not intended for Elsevier's services?
> 
> Our federation treats entitlement attributes in a special way in the sense that when implementing attribute release policies, we need to filter on attribute *values* as well as on attribute names.
> Our IDPs think this is important, for instance because they don't want entitlements used for the TCS Personal Certificate service to end up at other SPs. Sending those values to other SPs would leak information on who has administrator privileges for the TCS portals.
> 
> Operating a hub-and-spoke style federation, we have implemented filtering on our hub.
> I wonder how mesh federations handle this? What IDP software allows you to easily filter on attribute values? I know simplesamlphp can, but I'm not sure about others.
> 
> My apologies if you think I am drifting off-topic.

Very much ON topic in my view. This bears on how ePEntitlement can be used in various real situations. I'll be quite interested to hear from others about the question of filtering ePE values by SP. --Keith

> 
> Cheers,
> --
> Joost van Dijk
> SURFnet
> 
> 
> On May 15, 2013, at 3:25 PM, "Vries, Ale de (ELS-NYC)" <ale@xxxxxxxxxxxx> wrote:
> 
> > Our SP _generally_ requires the eduPersonEntitlement value, but coincidentally we've been running into the issue recently that more and more IdPs in more and more federations release multiple values for that attribute. Our assumption has always been that _if_ eduPersonEntitlement is used in any given federation, then just one value will be released for any given user at any given time - not multiple. So we're now faced with implementing logic to evaluate multiple attribute values to determine which of them may be valid for access to our products - which is not a small effort because of how deeply intertwined this logic is with our (already complex) authorization logic. Pending that implementation, we have simply decided to not check for eduPersonEntitlement value _at all_ for some federations, which means that in those federations some users may be getting access to our products while in fact they shouldn't.
> > 
> > 
> >> -----Original Message-----
> >> From: Keith Hazelton [mailto:hazelton@xxxxxxxx](javascript:main.compose()
> >> Sent: Tuesday, May 14, 2013 14:00
> >> To: REFeds
> >> Subject: [refeds] use of eduPersonEntitlement
> >> 
> >> An email thread here has me wondering whether IdPs outside InCommon
> >> tend to make much use of the eduPersonEntitlement attribute.
> >> 
> >> Any data points welcome.
> >> 
> >> --Keith Hazelton
begin:vcard
n:HAZELTON;KEITH;;;
fn:KEITH D HAZELTON
tel;work:608 262-0771
org:University of Wisconsin-Madison;DoIT
adr:;;1210 W. Dayton St.;Madison;WI;53706;US
email;work;internet:hazelton@xxxxxxxx
title:Sr. IT Architect
version:2.1
end:vcard