<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 6, 2016 at 3:56 PM Paul B. Henson <<a href="mailto:henson@cpp.edu">henson@cpp.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any other thoughts on this?</blockquote><div><br></div><div>Yes. The most likely explanation is that you have the releaseAttributes property of ValidateConfiguration set to false:</div><div><br></div><div>    <bean id="CAS.ValidateConfiguration.default" parent="CAS.ValidateConfiguration"</div><div>          p:resolveAttributes="false"> </div><div><br></div><div>That flag exists to preserve string CAS 2.0 protocol compliance, which does not define attributes. We actually do this at Virginia Tech because we found that some services break under (large amounts) of attributes with that turned on. It defaults to on, but it's possible you have turned it off.</div><div><br></div><div>Well, at least it _used_ to default to on. In reviewing source for this thread, it appears that r8178 effectively flipped the default to false. So assuming that analysis is correct, there's another explanation: you're running a very recent snapshot with that change and it's breaking you.</div><div><br></div><div>Please let me know if either of those explains the behavior you're seeing.</div><div><br></div><div>I should also note that the "resolveAttributes" flag is ignored for the /samlValidate endpoint in keeping with the behavior of other SAML endpoints in the IdP where attributes are always resolved.</div><div><br></div><div>M<a href="mailto:users-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>