<div dir="ltr"><div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace">We recently switched from using relying party lists to allow access to our IdP to filtering the metadata and using the DefaultRelyingParty entry to accept all SP&#39;s that we have valid metadata for.</div>
<div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace"><br></div><div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace">However we noticed that for entity id&#39;s were we didn&#39;t have a relying party entry, but were allowed to login because they were caught in the DefaultRelyingParty, the filters we defined stopped working if we used the AttributeRequesterString in the AttributeFilterPolicy.</div>
<div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace"><br></div><div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace">However by disabling the DefaultRelyingParty and setting up a relying party group for InCommon (using urn:mace:incommon). Then the filters picked up again.</div>
<div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace"><br></div><div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace">Is there a reason why AttributeFilterPolicys AttributeRequesterString would ignore the entity ID and not apply filters if using DefaultRelyingParty as opposed to RelyingParty.</div>
<div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace"><br></div><div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace">Note that the IdP allowed the login but simply didn&#39;t send the attributes defined.</div>
<div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace"><br></div><div><div dir="ltr"><font face="courier new, monospace">Jeffrey <div class="gmail_default" style="font-family:&#39;courier new&#39;,monospace;display:inline">
C.</div><br></font></div></div>
</div>