Is this a metadata error?

[Peter Schober]

* David Gersic <dgersic at niu.edu> [2013-05-28 18:42]:
> 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.

No, that's very probably fine. The IdP just told you (since you wanted
to know all about what it's doing ;) that there was no specific
relying party configuiration that said this SP should be handled
differently from other SPs, e.g. with regards to how SAML protocol
messages are to be encrypted or signed.
It has nothing to do with attribute release.

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

Well, if they're there in the resolver, but not after filtering, you
don't have filter rules in place that release them (the default is to
only sent for which explicit rules exist).

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

If you release ePPN to everyone, yes.

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

Please review
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPSPCommunicate
For every SP you already have a metadata source (and have attributes
resolved) the only thing that's left is the attribute filtering.

> 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"/>
[...]

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

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

Right,
-peter