Shibboleth Developers

[Walter Hoehn <>]

Alright, so basically the same feature.  The difference is that the  
IdP can only do this at the granularity of the attribute, whereas  
your extension can do it at the finer granularity of the value.

-Walter


On Sep 15, 2006, at 1:24 PM, Jim Fox wrote:

> > > 2) Make activation of the connector dynamic.
> > >
> > >   Using the same entitlement attribute as an example.
> > >   We usually know ahead of time which SPs will utilize
> > >   the group membership check.  It makes no sense to check
> > >   ldap for all the other SPs, to whom we wouldn't release the
> > >   entitlement anyway.  So we only activate the connector
> > >   for groups if the SP is one that might actually get
> > >   the entitlement.  The connector element looks like this:
> > >
> > >     <ActivationRequirement relyingParty="napster.com"/>
> >
> > Sorry, maybe I don't fully understand, but there's already an  
> > optimization in the IdP to do something similar to this  
> > automatically based on ARPs.
>
> Suppose I want to release to OCLC the entitlement
>
>  "urn:mace:incommon:entitlement:common:1"
>
> which is computed by an ldap request to the server holding
> general information about our users.  And I want to release
> to WebAssign the entitlement
>
>  "urn:mace:washington.edu:courses:SUM2006:12345"
>
> which is computed by searching a different ldap server
> for course membership information.
>
> So the ARP for each of these SPs includes a rule for
> eduPersonEntitlement, with conditional release values.
> The attribute resolver has to look up or compute the
> values for the attribute before it can apply the filter,
> thus it has to perform the course database search on
> every request from OCLC - even though that information
> will never be released.
>
> By adding the
>
>   <ActivationRequirement relyingParty="webassign"/>
>
> to the course database connector we eliminate all those
> unnecessary searches when the relying party is OCLC.
>
> Jim