Subject RE: use of eduPersonEntitlement
From "Vries, Ale de (ELS-NYC)" <ale@xxxxxxxxxxxx>
Date Thu, 16 May 2013 14:08:12 +0000

I only saw this response just now.

It's onerous because of the complexity of our access management system. For instance, we evaluate multiple credentials for a user at authentication time; users can be associated to different institutional accounts depending on that combination of credentials; and we have authorization rules that look at more than just SAML attributes. This leads to a lot of test cases that need to changed/developed and run through every time we touch that logic. 

> -----Original Message-----
> From: Cantor, Scott [mailto:cantor.2@xxxxxxx]
> Sent: Wednesday, May 15, 2013 11:16
> To: Vries, Ale de (ELS-NYC); Keith Hazelton; REFeds
> Subject: Re: [refeds] use of eduPersonEntitlement
> On 5/15/13 9:25 AM, "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.
> That is definitely incorrect, ePE is a multi-valued attribute, and always was.
> > 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.
> I really don't follow why handling multi-valued attributes is onerous.
> -- Scott