RE: use of eduPersonEntitlement

["Vries, Ale de (ELS-NYC)" <ale@xxxxxxxxxxxx>]

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