Shibboleth Developers

[Jim Fox <>]

> > 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

My present solution is to implement an "entitlement calculator",
which takes directives such as these:
( assume "epa" == "urn:mace:dir:attribute-def:eduPersonAffiliation"
     and "epn" == "...:eduPersonPrincipalName" )


  <CustomDataConnector id="UW-entitlements"
        class="edu.washington.EntitlementCalculator">
    <AttributeDependency requires="epa"/>
    <AttributeDependency requires="epn"/>

    <!-- define the 'library' entitlement -->
    <Entitlement value="urn:mace:incommon:entitlement:common:1">
       <Condition attribute="epa" value="staff"/>
       <Condition attribute="epa" value="student"/>
       <Condition attribute="epa" value="faculty"/>
       <Condition attribute="epn" 
value=""/>
    </Entitlement>
  </CustomDataConnector>


which gives us the "common:1" entitlement.  To get our new
napster entitlement we could add to the "calculator" config:

   <DataConnectorDependency requires="ldap-groups"/>
   <Entitlement value="urn:mace:washington.edu:music:dorm">
       <Condition attribute="cn" value="HFS.dormie"/>
   </Entitlement>


where the group with "cn" of "HFS.dormie" contains all students
who reside in the dorms.


For the time being, I added an "ActivationRequirement" element to
our subclass of the JNDI connector that causes it to actually
do the lookup only if the requirement is true, e.g.,

   <ActivationRequirement relyingParty="https://napster.etc./"/>



I think this will work for us for now.

Jim