Is this a metadata error?

David Gersic dgersic at niu.edu
Tue May 28 12:41:37 EDT 2013 

>>> On 5/25/2013 at 03:59 AM, Peter Schober <peter.schober at univie.ac.at> wrote: 

> Then the SP would only recieve the ePSA (which they probably already
> can handle, from what you said before about other customers/IdPs) and
> you can be sure it has nothing to do with ePPA not being processes

I'm pretty sure the problem is on my end (IdP) at this point.


> correctly at their end -- of course only after you've determined that
> you're actually sending the right stuff (set the first logger in
> logging.xml from INFO to DEBUG and either wait 10 min or restart the
> context/container).

Ok, so this has headed me in (I think) the right direction to get this figured out. Setting the IdP to DEBUG, I can see what's going on, but I don't yet understand why. In idp-audit.log I have:

10:31:33.904 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:
128] - Looking up relying party configuration for https://niu.universitytickets.com/shibboleth-sp

10:31:33.904 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:134] - No custom relying party configuration found for https://niu.universitytickets.com/shibboleth-sp, looking up configuration based on metadata groups.

10:31:33.905 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:157] - No custom or group-based relying party configuration found for https://niu.universitytickets.com/shibboleth-sp. Using default relying party configuration.

I'm pretty sure this is the problem. This SP shouldn't be using "default" for the relying party configuration.

I see it resolving the various available attributes via LDAP, so the problem isn't that the IdP can't get the values.

10:31:33.970 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:4
14] - LDAP data connector myLDAP - Found the following attribute: eduPersonPrimaryAffiliation[student]

10:31:33.985 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:314] 
- Resolving attribute eduPersonPrimaryAffiliation for principal xxxxxxxxxx
10:31:33.986 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:336] 
- Resolved attribute eduPersonPrimaryAffiliation containing 1 values

10:31:34.007 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:468] 
- Attribute eduPersonPrimaryAffiliation has 1 values after post-processing

10:31:34.015 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:137] 
- shibboleth.AttributeResolver resolved, for principal xxxxxxxxxx, the attributes: [eduPersonAffiliation, transientId, uid, eduPersonScopedAffiliation, eduPersonPrimaryAffiliation, sn, givenName, cn, telephoneNumber, eduPersonPrincipalName, mail, googleNameID]

Then I see it filter out pretty much everything, because none of the release rules (other than default) apply. The resulting set is:

10:31:34.027 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:114] - Filtered attributes for principal xxxxxxxxx.  The following attributes remain: [transientId, eduPersonPrincipalName]

There's a lot more in idp-audit.log of course, I'm snipping out the parts that I'm pretty sure don't matter for what I'm trying to do. The problem appears to be that the IdP doesn't think this SP should get ePPA, or anything else, other than the "release to anybody" attributes. Right?

Assuming that I'm right up to here, then the problem is on my end.


Looking in .../conf/relying-party.xml, I have the rp:RelyingParty definitions here for Anonymous and Default, and I've added one for Google (which is working). After that, I have the metadata:MetadataProvider definitions for the IdP itself, InCommon.org, and Google. After that, I have the Security Configuration section.

What I wanted, and thought that I had configured, is that any SP in the InCommon.org metadata should have these eduPerson attributes released to them: eduPersonAffiliation, eduPersonPrimaryAffiliation, and eduPersonEntitlement.


So in .../conf/attribute-filter.xml I have this defined as:

    <!--  Release eduPerson attributes to Incommon.Org federation  -->
    <afp:AttributeFilterPolicy id="releaseToIncommonDotOrg">
        <afp:PolicyRequirementRule xsi:type="saml:AttributeRequesterInEntityGroup" groupID="urn:incommon.org"/>

        <afp:AttributeRule attributeID="eduPersonAffiliation">
            <afp:PermitValueRule xsi:type="basic:OR">
                <basic:Rule xsi:type="basic:AttributeValueString" value="faculty" ignoreCase="true" />
                <basic:Rule xsi:type="basic:AttributeValueString" value="student" ignoreCase="true" />
                <basic:Rule xsi:type="basic:AttributeValueString" value="staff" ignoreCase="true" />
                <basic:Rule xsi:type="basic:AttributeValueString" value="alum" ignoreCase="true" />
                <basic:Rule xsi:type="basic:AttributeValueString" value="member" ignoreCase="true" />
                <basic:Rule xsi:type="basic:AttributeValueString" value="affiliate" ignoreCase="true" />
                <basic:Rule xsi:type="basic:AttributeValueString" value="employee" ignoreCase="true" />
                <basic:Rule xsi:type="basic:AttributeValueString" value="library-walk-in" ignoreCase="true" />
            </afp:PermitValueRule>
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="eduPersonPrimaryAffiliation">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="eduPersonEntitlement">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

In .../conf/relying-party.xml I have InCommon's metadata defined as:

        <!-- Metadata for InCommon Federation -->
        <metadata:MetadataProvider id="InCommonMD" xsi:type="metadata:FileBackedHTTPMetadataProvider"
                          metadataURL="http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml"
                          backingFile="/share/shibboleth/shibboleth-idp/metadata/InCommon-metadata.xml"
                          failFastInitialization="true"
                          requireValidMetadata="true">
            <metadata:MetadataFilter xsi:type="metadata:ChainingFilter">
                <metadata:MetadataFilter xsi:type="metadata:RequiredValidUntil" 
                                maxValidityInterval="P21D" />
                <metadata:MetadataFilter xsi:type="metadata:SignatureValidation"
                                trustEngineRef="InCommon.MetadataTrustEngine"
                                requireSignedMetadata="true" />
                    <metadata:MetadataFilter xsi:type="metadata:EntityRoleWhiteList">
                         <metadata:RetainedRole>samlmd:SPSSODescriptor</metadata:RetainedRole>
                    </metadata:MetadataFilter>
            </metadata:MetadataFilter>
        </metadata:MetadataProvider>

And, I see this SP in InCommon's metadata as:

<EntityDescriptor entityID="https://niu.universitytickets.com/shibboleth-sp" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">


Re-reading the IdP docs, I *may* have figured out what's wrong.

InCommon's metadata starts with:

<EntitiesDescriptor xmlns="urn:oasis:names:tc:SAML:2.0
:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="INC20130524T184550" Name="urn:mace:incommon" validUntil="2013-06-07T23:00:00Z" xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:metadata sstc-saml-schema-metadata-2.0.xsd urn:mace:shibboleth:metadata:1.0 shibboleth-metadata-1.0.xsd http://www.w3.org/2000/09/xmldsig# xmldsig-core-schema.xsd">

The "Name" here is "urn:mace:incommon", which doesn't match the groupID ("urn:incommon.org") in attribute-filter.xml. But I think it should, at least if I've understood the doc for AttributeRequesterInEntityGroup correctly.

So to fix this, I need to change attribute-filter.xml to use the correct groupID ("urn:mace:incommon") so that it matches the Name that is in the InCommon.org metadata.

Right?

More information about the users mailing list