Refeds


Subject RE: use of eduPersonEntitlement
From "Vries, Ale de (ELS-NYC)" <ale@xxxxxxxxxxxx>
Date Wed, 15 May 2013 16:00:43 +0000

Actually, in the specific case of SURFconext we encountered this issue not because of multiple values being released, but because of the same value being released in two different formats - urn:mace:<name> and urn:mace:<oid>. Our access management system choked on that - and it's currently being worked around by the SURFconext hub, IIRC. 

> -----Original Message-----
> From: Joost van Dijk [mailto:Joost.vanDijk@xxxxxxxxxx]
> Sent: Wednesday, May 15, 2013 10:20
> To: Vries, Ale de (ELS-NYC)
> Cc: Keith Hazelton; REFeds
> Subject: Re: [refeds] use of eduPersonEntitlement
> 
> 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.
> 
> 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]
> >> 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