ebsco, proquest configuration?

[Don Faulkner]

Would anyone care to share details of a working ebsco or proquest configuration?

I've run into a dead end configuring attribute resolution and release for ebsco. We had it working briefly in April, but had to pull it out when it broke our google release[1]. Now, I'm trying to put it back in and not getting anywhere. I'm getting ebsco's "Error 103" message, without much indication what's wrong. i'm not getting a lot of help out of ebsco right now. I've been told that they only have tools to debug UK Shibboleth users.

We're releasing eduPersonScopedAffiliation and eduPersonEntitlement, as you can see here:
    <afp:AttributeFilterPolicy id="ebscohost">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="http://shibboleth.ebscohost.com" />
        <afp:AttributeRule attributeID="eduPersonEntitlement">
            <afp:PermitValueRule xsi:type="basic:AttributeValueString" value="urn:mace:dir:entitlement:common-lib-terms" />
        </afp:AttributeRule>
        <!--
        <afp:AttributeRule attributeID="eduPersonEntitlement">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
        -->
        <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>


Since we don't yet have directory information to resolve from, I've tried eduPersonEntitlement two ways:

First, as an AttributeValueString in attribute-filter.xml:
<afp:PermitValueRule xsi:type="basic:AttributeValueString" value="urn:mace:dir:entitlement:common-lib-terms" />

Second, as a static data connector in attribute-resolver.xml:
    <resolver:DataConnector id="staticAttributes" xsi:type="dc:Static">
        <dc:Attribute id="eduPersonEntitlement">
            <dc:Value>urn:mace:dir:entitlement:common-lib-terms</dc:Value>
        </dc:Attribute>
    </resolver:DataConnector>


eduPersonScopedAffiliation is resolved from the object classes attached to the LDAP entry for the user account, via a script in attribute-resolver.xml:
    <resolver:AttributeDefinition xsi:type="Script" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                    id="eduPersonAffiliation" sourceAttributeID="eduPersonAffiliation">
        <resolver:Dependency ref="uarkLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:mace:dir:attribute-def:eduPersonAffiliation" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                    name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" friendlyName="eduPersonAffiliation" />

        <!-- The script, wrapped in a CDATA section so that special XML characters don't need to be removed -->
        <Script><![CDATA[
            importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);

            // Create attribute to be returned from definition
            eduPersonAffiliation = new BasicAttribute("eduPersonAffiliation");

            // Add at least one value
            eduPersonAffiliation.getValues().add("affiliate");

            // If the user has group membership
            if (typeof objectClass != "undefined" && objectClass != null ){
                // The go through each objectClass value and add the appropriate affiliation
                // The IdP will remove duplicate values so we don't need to worry about that here
                for ( i = 0; objectClass != null && i < objectClass.getValues().size(); i++ ){
                    value = objectClass.getValues().get(i);

                    if (value.indexOf("uaoFaculty") > -1){
                        eduPersonAffiliation.getValues().add("member");
                        eduPersonAffiliation.getValues().add("employee");
                        eduPersonAffiliation.getValues().add("staff");
                        eduPersonAffiliation.getValues().add("faculty");
                    }
                    if (value.indexOf("uoaStaff") > -1){
                        eduPersonAffiliation.getValues().add("member");
                        eduPersonAffiliation.getValues().add("employee");
                        eduPersonAffiliation.getValues().add("staff");
                    }
                    if (value.indexOf("uoaStudent") > -1){
                        eduPersonAffiliation.getValues().add("member");
                        eduPersonAffiliation.getValues().add("student");
                    }
                    if (value.indexOf("uoaApplicant") > -1){
                        eduPersonAffiliation.getValues().add("member");
                    }
                    //uoaRetired and uoaAffiliate only get the affiliate designation that all get
                }
            }
    </resolver:AttributeDefinition>



[1] Really, it was the poorly documented "don't release transientID to google" that broke, but we were really green then.
--
[me]
Don Faulkner, CISSP | IT Security<http://its.uark.edu/> at the University of Arkansas<http://www.uark.edu/>
contact>> donf at uark.edu<mailto:donf at uark.edu> | +1 (479) 575-2905
connect>> uarkITS on Facebook<http://www.facebook.com/uarkITS> | @uaits<http://twitter.com/uaits> | @dfaulkner<http://twitter.com/dfaulkner>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20121114/fe26e46f/attachment-0001.html