Shibboleth Developers

[Walter Hoehn <>]

This bounced back to me, so I'm retrying...-0500


> From: Walter Hoehn 
> <>
> Date: July 14, 2005 11:28:15 AM CDT
> To: Jim Fox 
> <>
> Cc: Shibboleth Developers 
> <>
> Subject: Re: generating eduPersonEntitlements
>
>
> Some thoughts... none of this represents a solution to your problem:
>
> Your question naturally leads to another.  Is this sort of  
> attribute aggregation the job of the IdP software or of an  
> enterprise directory?
>
> When this was discussed some time ago, there wasn't really a  
> consensus.  The attribute resolver subsystem was written as an  
> attempt to be agnostic on this question.  If you have an enterprise  
> directory with all of the relevant data, it mostly works out of the  
> box.  If not, it gives you a framework for retrieving the data from  
> wherever it happens to reside, and massaging it appropriately on  
> the way out.  In the name of efficiency, the resolver does  
> selectively compute attribute values depending both on what has  
> been requested by the SP and what the release policies allow the SP  
> to receive.
>
> As you noted, this optimization only works at the granularity of an  
> attribute, not at a particular value.  For most simple attributes  
> this won't ever be an issue; but eduPersonEntitlement is peculiar  
> in that it is sort of a roll-up view of a particular policy, so it  
> is much more likely that computation will be needed to generate the  
> values.
>
> -Walter
>
>
> On Jul 13, 2005, at 11:27 PM, Jim Fox wrote:
>
>
> > > It supports it via attribute plugins. I'm not sure how else it  
> > > could be
> > > supported. I guess some kind of generic group query connector  
> > > that results
> > > in an entitlement?
> >
> > Yes, the CustomDataConnector supports most things we need, but not
> > efficiently.  The problem is the overloaded nature of ePEntitlement,
> > which really ought to be a different attribute for each SP.
> >
> > Suppose I have SP-1 that wants an entitlement that's hard to  
> > compute -
> > say it accesses a database somewhere.  And an SP-2 entitlement that
> > accesses some other database.  And SP-3 that only wants "member".   
> > Now
> > I have only one chance to define an attribute connector for  
> > ePEntitlement
> > - so it has to include data connectors for every possible SP.  My  
> > arps
> > also can only reference ePEntitlement.  They can later filter values,
> > but only after those values have been computed.  So, on every  
> > access from
> > SP-3 I have to compute the ePEntitlement attributes for SP-1,  
> > SP-2, and
> > every other SP, only to filter them all out and return "member".
> >
> > What I really want is "Entitlement-sp-1", which I compute only if the
> > SP is SP-1; "Entitlement-sp-2", which I compute if SP-2; and the
> > "Entitlement-sp-3", which I compute if the SP is SP-3.  Before  
> > responding
> > with attributes I combine all the "Entitlements*" into one
> > "eduPersonEntitlement" and send that.  This way I can avoid the
> > time-consuming calculations for entitlements that I know I will  
> > not need.