<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">I'll try the aacli tool and see what it reports, I won't be able to do it today since this is in production and the system is being used quite heavily today. I'll have to take one of the instances offline and then perform the command and see what the results are.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">I can't imagine this would be important but our IdP has two entity ID's one is for non inCommon relying parties where we have the IdP's metadata published on a url, and the second is used for inCommon relying parties. We change the "provider" on RelyingParty entries depending on which case we are working with on a particular Service Provider. However I'm using the same provider entry on the DefaultRelyingParty as the urn:mace:incommon RelyingParty group id.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">I'm not able to reproduce this in our test environment but the big difference there is that we only use a single entityID since it's not in inCommon.</div>
<div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font face="courier new, monospace">Jeffrey <div class="gmail_default" style="font-family:'courier new',monospace;display:inline">C.</div></font><div>
<font face="courier new, monospace">---------------------------------------</font></div></div></div>
<br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 11:03 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One thing you probably want to do is to debug the filter policy using the<br>
aacli tool and make sure the policy fires based on setting the requester<br>
option there.<br>
<br>
Once that works, I have no idea how any change to relying-party.xml can<br>
affect the policies other than by preventing the attributes from<br>
resolving, so I'd be looking for comparisons between the log in the aacli<br>
case and the actual SSO case during the attribute resolver step, and what<br>
gets passed to the filter.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div></div>